Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging.
There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.
Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?
The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
I did a demonstration using GnuPG to provide a practical example:
"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
I have some issues:
First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated.
Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device.
Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients.
Just to make this point more clearly:
> it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption.
----
> Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
>...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous.
I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.
You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.
> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.
They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.
----
There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
