That's not what you're demanding. You're demanding the end to a UX. That's entirely orthogonal to security, and my whole point is that's very different from pushing people to go from an insecure version of a UX to a more secure version of a UX (or at least a strict superset of that UX). It's straight forward to argue "don't use HTTP, use HTTPS", or "don't use SMS, use {secure messenger}"[1], or "don't use POP, use POPS or IMAPS" or even "don't use an 8 character password that is the name of your dog on a website, use something random and preferably a password manager".

But that's not your argument.

1. Though again, the basic fact that I can't just tell anyone in the world, on any device at all, what {secure messenger} vs "SMS" should be is inherently suboptimal though less so.

Already a thing, next?

> forward secrecy

There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.

Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.

If you want that handshake for email, I don't know how to do that without giving the long term keys to the mail server, which in most cases is operated by a third party that reads your emails for a living. I'd love to have a solution for that, but I don't believe there is any.

Simply put, forward secrecy doesn't make much sense in the context of email.

It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport. But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".

The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online.

If the recipient is not online, as is expected of asynchronous communication applications such as email, an intermediate server has to hold the message for him. At this point, you either give up on the handshake, or hand over the secret key to the server.

Good luck setting up a trustworthy server. Even if I hosted my stuff at home, I might not be too keen on leaving it on where it could be examined by forensics while I am away. It's not bad, but it's not perfect either. And forget about third party servers, they are untrusted by default. I'd rather give up forward secrecy instead, and keep my private key on an encrypted file on my personal laptop.

So we can't have that hand shake. The protocol has to look like: (i) Alice and Bob know of each other's long term public keys. (ii) Alice encrypts then send a message to Bob. (iii) Bob receives then decrypt that message.

If I knew of a protocol that followed those constraints and still preserves forward secrecy, you could be damn sure I'd put it in Monocypher—one less thing the user could screw up. (Actually, I'd love to be proven wrong there, it would improve my crypto library right away.)

> It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport.

You'd still have to give the long term keys to a machine that is online when the message is sent. For asynchronous protocol, this means always online, and we're back to square one.

> But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".

Are you implying that forward secrecy is required for "security"?

Am I "implying" that forward secrecy is required for message security? No, I'm saying it directly.

OK, I'll look it up, thanks. Though I suspect I already have (the 3-DH the Wikipedia mentions looks familiar, I suspect it is X3DH). Better than nothing, but not quite perfect.