More generally, the OpenPGP world is in a bit of a double-bind: they can either fix things by breaking compatibility (at which point someone can reasonably observe that there's no good reason not to ditch OpenPGP entirely), or retain compatibility and accept that OpenPGP will never get much better than RFC 4880 and whatever smattering of drafts the GnuPG maintainers agree to implement. One way essentially results in an entirely different tool/standard that happens to be wearing PGP's skin; the other means keeping around misuse-prone and outright broken cryptographic primitives (and bad formats to boot).
(To answer your actual question: email is just a bad substrate for attempting E2EE messaging. Latacora has a great explainer post on why[1]. TOFU is a mostly adjacent concern; trust/identity negotiation is hard, but the thing that makes WhatsApp, Signal, etc. actually work is that they eliminate manual key management and make cryptographic right choices for the user, rather than expecting the user to hold the tool correctly. In other words: they're misuse-resistant, where PGP as an ecosystem has historically not been.)
[1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
(Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)
(But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)
Is that not tofu, which is easy in many crypto systems?
In other words: you always need to perform OOB identity verification, regardless of your messaging system of choice. There is no way around this; it’s a fundamentally social and UX problem rather than a cryptographic one. But this doesn’t change the fact that, once you have a trusted identity, Signal’s MITM protections are significantly stronger than PGP’s (including forward secrecy, as noted before).
Web-of-trust alleviates that, to some extent.
(I think WoTs can solve these problems. But PGP's implementation has been so far the most ambitious tried by a semi-large audience, and it didn't hold up. We need a better starting point.)
This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.
The assumption underlying much of the post is that PGP is only used in offline, stateless applications. This would make the arguments stronger, except that it isn’t true[1].
It's really OCFB-MDC. It's only a authenticated mode when the two things are used together (like GCM). It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. I don't know what "true AEAD" means in this context. As a user I only care that the OCFB-MDC mode is actually secure. I am not interested in any philosophical aspects.
The stuff about offline stateless applications only adds to the argument. A version of OCFB-MDC could be used, for say, TLS and would be expected to be secure.
It isn't sensible to assert this, because people use OpenPGP in all kinds of crazy ways. One of the recurring headaches in applied cryptographic engineering is discovering that people do, in fact, attempt to use PGP for instant messaging (per above), as a TLS certificate delivery mechanism, etc. These are contexts where the use of an AEAD is frequently appropriate.
> As a user I only care that the OCFB-MDC mode is actually secure.
In practice, it has not been[1]. PGP's decision to use MDC instead of a real MAC is a classic example of home-rolled primitives being conceptually algebraically sound but broken in user settings. The solution here is simple: OpenPGP is not special, and should use a MAC or AEAD mode like everyone else does. It also shouldn't release the plaintext until the authentication tag is actually validated, which was another profound historic breakage with MDC.
[1]: https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw...
>PGP's decision to use MDC instead of a real MAC...
The MDC can be interpreted as a MAC. The hash is first seeded with a MAC key (the "random block"). So a boring old hash MAC. SHA-1 is vulnerable to length extension attacks but that is not an issue here as the attacker never gets access to the state of the hash (everything is encrypted). I guess this could be considered an advantage of MAC then encrypt. The only property the hash requires is that the MAC key will be propagated to the check value in such a way that it is indistinguishable from random. So SHA-1 is wild overkill here.
The challenge is that there’s no money to be made so you’d need a non profit like Signal to do it to disrupt that industry.
It felt a small team or a single person project. There was a cat and mouse game being played against Gmail interface changes, with the encryption being broken every now and then. It required me, a random user, to trust the extension developer(s) with my Gmail and gpg keys. I had fear of having an xz backdoor situation compromising my Gmail account and gpg keys.
And for this extension to succeed I also had to convince all my Gmail friends and contacts to use it, and convincing them to trust the developers of the extension as I had done.
While I felt confident that the extension was perfectly safe I didn't dare to convince my family and friends to use it because (a) I could not guarantee that the extension wouldn't be compromised in the future and (b) the chance of the extension being broken in the future due to a Gmail UI change was close to 100%. Also the more users the extension had the higher the chances for someone to attempt to infiltrate to attempt a backdoor...
If I recall correctly, eventually the developer got tired of the Gmail UI changes and increasing demands of users and moved on, stopping the development.
Anyone with time could try to develop such an extension, but there were drawbacks back in the day...
For example, you could run a proxy server to deliver the messages between parties. So if you’re emailing someone, the browser extension changes the address to be a server you control, sends you the encrypted email that has everything meaningful encrypted, you decrypt the part your able to (ie the intended receiver) and forward that.
As far as either email server is concerned, your email server is sending out and receiving encrypted emails but there’s no metadata to connect anyone. The key handling uses your access to the email account to validate access same as signal uses the phone number.
That seems like a pretty close system to how Signal works and I don’t see anything meaningfully different. If you do, can you actually elaborate? I don’t feel like the link you pointed me answers why my proposal would be larping security since the security and threat model feels very similar to Signal.
Here are some choice quotes I pulled out of that link and why I have problems with the claims made:
> Searchable archives are too useful to sacrifice, but for secure messaging, archival is an unreasonable default. Secure messaging systems make arrangements for “disappearing messages”.
Signal and most apps except Snapchat (which isn’t e2e afaik) don’t archive by default. But yes, it is true that having encrypted web mail and search are incompatible whereas messaging apps store the data locally and thus can provide search. You’d need a dedicated client that could store all the encrypted messages locally but people aren’t as used to for that.
> Some email clients have obscure tools for automatically pruning archives, but there’s no way for me to reliably signal to a counterparty that the message I’m about to send should not be retained for more than 30 minutes.
Talk about security LARPing. Once the message is sent you’ve lost all control of it. Your just following social contracts that the app honors the request and the user is using an unmodified app.
> No matter how good a job one does securing their own data, their emails are always at the mercy of the least secure person they’ve sent them to.
Also true for messaging apps
You could just email each other your Signal ids at that point. It's no longer the email everyone thinks of as email.
Nothing stops you from implementing a similar mechanism based on email addresses.
i.e. WhatsApp and Signal care about UX and mainstream adoption. Nothing like that for email has tried to do PGP.
And that is where they get their usability
They are 3 particular paths that aren’t in any way open to most attackers but will work here.
Saying it impacts all applications isn’t wrong but it’s also not relevant to what was asked.
If whatever the hell you are doing requires a threat model where the NSA is interested in finding out who you are talking with and what you are saying the original comment of signal is inappropriate is 100% accurate.
It’s a criticism of the platform, not applications running on it.
Yes, phone operating systems are more modern, and implement: sandboxing, hardware security, MAC, app permissions, etc. That’s why they do less. In this category, I would use iPadOS in lockdown mode.
But a phone is a device for the every day use of an average user. It’s not designed to be a security device to protect people against targeted attacks. If your threat model is a state actor, you might be better off with a desktop. Phones have phone numbers and take unauthenticated input from the external sources (messages). There is an opaque baseband chip. The threat model in which they are secure is skewed in favor of the phone provider: essentially you rent their device, and share your information. Phones communicate information about user such as the location, and might conveniently backup users data to the external servers by default. There is limited app choice. You can’t inspect, select and customize a phone OS. On the other hand, I can cherry pick a desktop OS, even build one selecting components, see, monitor and control the software, and run it on hardware from a source I trust.
I'm not saying this to convince you, just to establish that we are definitely talking about the same thing, and I am definitely not being flippant.
So for instance, if you are using signal to do an outreach and support operation for a human rights group operating in China, it might be reasonable to assume that some Chinese intelligence orgs can view your plaintext. The strategy would then be to not transmit any information that would allow a decisive action against the group. The opportunity cost of revealing the surveillance has to be greater than the utility of acting on the intelligence. But obviously this would compromise the scope of assistance you could provide.
And the risk is iffy, for a few reasons that I've thought of since seeing your response:
1) PGP key exchange has the same problems when done over the network. Doing foreign outreach via PGP has the same problems.
2) I don't know of any examples of Signal MITM attacks stemming from weak key exchange. Worse, I don't actually know how key exchange works on signal
4) Key exchange problems are more of a universal nitpick against all crypto systems, not a full compromise
I'd be curious about your feedback - even if it's a chastisement.
I am also curious if you feel signal has any REAL issues which keep you up at night, if not key exchange.
On individual level, if you have being targeted or use a tool with 0day then you lost before you even know that there was a game.
PGP could have a phone app that will do easy encryption, such as protonmail.
Amazing that you consider a proprietary thing like whatsapp remotely secure. For all we know it's backdoored.
And signal… not available on fdroid… thus mostly installed via apple/google… how difficult would it be to push a backdoored update to selected individuals?
GPG is more secure
They both use a centralized, authority for identification and key sharing, sidestepping the hardest part entirely. Also, they are their own protocol and as such you don't suffer the encrypted/plain-text-only email dichotomy, sidestepping another pain point.
When you don't care about the decentralized nature of email and can force everything to be encrypted, then the problem becomes much easier.
Is it really because trust on first use is good enough for most cases? Or is email somehow so much different than chat? Or was PGP the proof-of-concept, and current e2e encrypted platforms are the v1.0? Or all of the above? Did I miss anything important?