[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.