[p2detar]

The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys.

Then there were a whole plethora of products were build around Lotus Notes Domino that provided a central place for securing outgoing E-mail using either S/MIME or GPG keys. All of this on premises. Then came the Cloud and obliterated these products. And for what?

edit: typos

[bigfatkitten]

> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys.

It was never really solved, PGP email is a usability disaster.

Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire conversation is exposed. Key exchange with new recipients is tedious to do securely.

Not to mention the extra issues caused by HTML in message bodies.

https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you...

[AshamedCaptain]

Ah, the usual "A is an unpopular standard, so we decided to do our own proprietary thing". Guess what: for it become popular, it actually has to be implemented. If Google implemented it in Gmail, many of these purported issues would go away . It would still not truly be E2EE mail, but then again neither is this monstrosity.

[Telemakhos]

While I'm sure some of these flaws also apply to S/MIME, I feel like its client support (even in Apple iPhone native mail app) is far superior to PGP. Apple made S/MIME installation and use across its ecosystem, and I remember it being easy in kMail once upon a time when I used KDE; why didn't S/MIME ever catch on?

[p2detar]

It did, but on enterprise level. S/MIME uses the CA hierarchical trust model, which is centrally managed and much more compatible with how internal enterprise structures are built. In a large enterprise you would have IT managing your AD/CS and therefore also managing the issuing, revocation and so on of employee certificates. But for the public this model of management isn't really practical.

[bigfatkitten]

I've worked in an org that used S/MIME heavily.

In a managed environment, you also get the advantage of certificates stored in a central directory (LDAP etc), and so certificate selection for the client is seamless.

All you have to do is hit "encrypt" in your mail client, enter your smart card PIN and the machine does the rest.

[p2detar]

Indeed using PGP for personal E-mail was never easy and required sufficient knowledge from end users. Using it in corporate setups was a piece of cake and I've seen it personally. I had been using and working on software that manages PGP keys centrally, end users did not have to do anything about encryption or signature verification. The problem was indeed solved. Arguably that is what Gmail tries to (poorly) do right now.

> Not to mention the extra issues caused by HTML in message bodies.

Proton Mail came out with a pretty good statement about this and I fully agree.

> Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk.

https://proton.me/blog/pgp-vulnerability-efail

[aborsy]

It’s a disaster because email providers don’t want to offer E2EE or make it easy.

Is it that hard to generate a certificate for each email address client side and store that, and the private key encrypted with the user’s password, on the provider’s server?

The majority of email is gmail and Google could make that E2EE by default.

Countless products that have successfully implemented public key distribution (proton mail, instant messaging, …).

[bigfatkitten]

This would be a reasonable proposition if the entire Internet mail system was run by 3-4 operators, and there were no mail clients at all other than service provider webmail.

Unfortunately, the real world is much more complicated than that.

[pas]

that's not the hard part. it's the out-of-band key exchange. (or key discovery/verification. so basically how to avoid the trust on first time use problem.)

[aborsy]

The certificate contains email address as ID, and email is verified automatically or by an initial email verification (TOFU trust model).

If Google, Microsoft and Apple offer E2EE similar to Proton, the majority of email will be encrypted, as long as both sides use the same service, or globally if these companies share public keys for public key discovery.

[taneq]

> And for what?

Job security. The software industry was built on the premise that users would buy all new software and hardware every 3 years. In the mid 2000s they collectively realised that software was ‘good enough’ for most users, and that it doesn’t wear out.

SaaS, the subscription model, “the cloud”, they’re all about making the user pay more than once for the same software.

[josephg]

For PGP keys to work, users also need to publicly broadcast who they know and personally trust. It’s a privacy disaster.

[upofadown]

You can just send your PGP key to your correspondents attached to an email. There is even a mime type for it. There is no need for any public broadcasting.

The big problem is verifying identities. The usability of that is an unsolved problem that plagues encrypted messaging of all kinds. So sure, signing PGP keys as a form of introduction is awkward, but at least it is possible. How do you vouch for, say, a Signal user?

[josephg]

If I attach a pgp signature in an email, it’s trivial for a MITM attack to replace my signature with their own. Without any way to verify who owns the key that was used to sign your message, what good is it? I suppose I could publish my key on my website too, but that’s a usability nightmare for everyone involved. A mitm attack could also just strip off the signature and alter the message I would be none the wiser.

Signal uses a much more complex key ratcheting system. It’s TOFU, but the key rotates with each message I send. The first message is vulnerable to a MITM attack, but because of the way signal works, if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure. The earlier keys are also published to make messages deniable. (Aka OTR).

Even then, if you want to verify who you’re talking to, you can click on someone’s name in signal and click “View safety number” and verify the code through a separate channel. Like, in person or over a text message or something.

Because your code is different for every conversation, it protects against correlation attacks. That is to say, a 3rd party watching the traffic can’t tell that all of the messages you send to different recipients came from the same person. Email+PGP doesn’t encrypt the most important information - which is the identity of the sender and receiver.

Signal is way better than pgp-over-email in every regard. The UI is better. There’s no encouragement to publish your keys or your social network. And the security ratchet is better than the static key that pgp uses. I’d pick it every time.

[upofadown]

We are talking about public keys here, not signatures.

>It’s TOFU, but the key rotates with each message I send.

You seem to be confusing the Signal long term identities with forward secrecy.

>...if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure.

This isn't true. Signal verifies identities the exact same way PGP verifies identities. As with PGP if you haven't checked your "safety numbers" you can't be sure your messages are actually ending up with your correspondent.

>Because your code is different for every conversation, it protects against correlation attacks.

PGP normally uses a different session key for each and every message ... but that isn't really relevant for either the Signal or PGP case if we are talking about correlation. For efficiency and convenience each message is normally tagged with the encryption key fingerprint of the recipient but you can turn that off if that might be a problem in your particular application. At that point there is nothing an observer can use to determine anything about the sender or receiver.

You probably meant to reference Signal's "sealed sender". It doesn't really work in practice:

>https://www.ndss-symposium.org/ndss-paper/improving-signals-...