SSH uses asymmetric crypto to authenticate, and then negotiates session keys. That’s how most modern PKI systems actually work. TLS is a great example: all actual traffic is encrypted symmetrically, and all modern ciphers use forward-secret session key negotiations.
And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure.
For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.
Yes, but anyone with my SSH keys can connect with SSH.
> but give the user an illusion that what they’re saying is secure.
I don't trust any encryption system with my life or the nuclear launch code. But for casual privacy, the scheme I proposed is fine.
> I’m using your old key, the one I have
Then my system should bounce it back saying the key is invalid. Of course, if I change my key the email app should send a "new public key" email to my address book.
I said long-lived keys for data encryption is a pitfall, you pointed out SSH uses long-lived keys, I said it doesn’t use them for data encryption, and now you’ve just said an unrelated true thing about SSH?
There’s a huge valley of users between “casual privacy” and “nuclear launch codes”. Most humans live there. If your pitch is that your system is a casual privacy tool, just use email. Casual threats aren’t doing dragnet email surveillance or hacking email providers.
> If your pitch is that your system is a casual privacy tool, just use email
The lock on my front door is easily circumvented by anyone determined to get in. But we still use door locks, and locks are far more effective than otherwise.
My proposal is ridiculously simple. All it requires is to standardize a single tag in the email protocol which provides a public key and agrees on a particular public key method. That's it.
Email apps can support it, or not, it still works. Even if just gmail supported it, or Thunderbird, or Outlook, it will be viable.
An Email is not analogous to a house, it's more akin to a tent, or a lean-to; A simple solution to a simple problem.
Tent: How can we build a serviceable shelter that can be quickly un/packed, built, and costs next to nothing?
Email: How can we enable everyone to send messages to everyone else with as little inconvenience as possible?
Both solutions solve the stated problem, and that's it. If I want a secure shelter, a tent alone will not suffice, I have to build a ditch&wall around it. Similarly, if I want secure communication, I have to encrypt the message before sending it via Email.
SMTP is not made to be secure, because that's not the problem domain it concerns itself with.
And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure.
For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.