[masklinn]

Indeed, from Latacora's recent "The PGP Problem":

> Encrypting Email

> Don’t.

> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.

> If you needed another reason, read the Efail paper. The GnuPG community, which mishandled the Efail disclosure, talks this research down a lot, but it was accepted at Usenix Security (one of the top academic software security venues) and at Black Hat USA (the top industry software security venue), was one of the best cryptographic attacks of the last 5 years, and is a pretty devastating indictment of the PGP ecosystem. As you’ll see from the paper, S/MIME isn’t better.

> This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending?

> Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.

[DarkWiiPlayer]

If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control.

If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance.

A possible counter argument could be this: You already need to trust a recipient that they won't leak the data you send them willingly and with harmful intent, so it's not that much to ask that people also trust the competence of the recipient.

What Opmsg really seems to be about is cases where you don't trust the recipient to not betray you, intentionally or unintentionally.

[tptacek]

No. Secure Messengers are designed to be hard to use unsafely. Nobody accidentally sends plaintext to a counterpart with Signal, because there's no feature in Signal that does that.

[chacha2]

Strange example. Signal does support unencrypted sms which would make it easy for someone to forward a previously encrypted message as plain text.

[cwyers]

If you can't trust the recipient, there's nothing you can do. The point isn't to protect yourself from an untrustworthy recipient, it's to protect yourself from inadvertent disclosure.

[hiq]

You can still send text messages (including to Signal contacts by long-pressing the send button). Obviously it is harder than just sending an encrypted message.

[jcranmer]

Email is really difficult-to-impossible to secure correctly.

Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subject header), and has done so for 15 years, but I'm unaware of any email client that actually supports this feature, and the downgrade mode is pretty UX-hostile.

Another very challenging problem is that the flow of email pretty much destroys any chance of using a good secure cryptosystem. The email sender is not necessarily able to establish a direct, synchronous contact with the email recipient, even on a server basis. That makes protocol negotiation and perfect forward secrecy difficult. Not to mention that users generally expect to be able to open up email clients on unknown machines (especially webmail clients), which means practical key distribution tends to amount to "give your provider your keys," at which point the security advantage over the current state of all-connections-are-wrapped-in-TLS is negligible.

There's also the point that email's main advantage as a messaging system is its universality. But any new protocol is going to suffer from being supported in a small section of clients at first. If you can't get major email clients on board--and that includes webmail clients--then the universality of email is no longer an advantage in your proposed protocol. And if you're going to have to use a different client already, why bother with doing all the crap you have to deal with email syntax, MIME, SMTP, and IMAP?

About the only use case I can reasonably see for encrypting emails is in workflows like Bugzilla's "secure email" feature: the system is already relying on email for communication, there is a clear way to handle the recipient's key and protocol negotiation, and the metadata is irrelevant to secure.

[Mediterraneo10]

Doesn’t To and From metadata leak on encrypted-message apps, too? WhatsApp, Telegram and Signal use mobile phone numbers as identifiers. In many countries now, you cannot buy a SIM card unless you show the vendor proof of identity, a copy of which is then provided to the state for its records. Therefore, any state actor that can put pressure on those encrypted-messaging services can reveal which phone numbers are talking to who, and therefore who is talking to who. Sure, the message text might still be secure if the end-to-end encryption works, but the metadata is vulnerable.

[AnaniasAnanas]

> WhatsApp, Telegram and Signal use mobile phone numbers as identifiers

One notable exception (which as I understand is tptacek-approved) is Wire, which only needs an email.

[tptacek]

I concede that Wire has essentially lifted the core crypto bones from Signal. But metadata collection is a clear distinction between Signal and Wire, so if what 'jcranmer is saying about email metadata is persuasive to you, your choice between Wire and Signal should be clear: use Signal, not Wire.

[tinus_hn]

Well that settles it. Better do nothing then!