3 ms·

But PFS is specifically about including "my adversary may, at a later date, compromise my private key" in your threat model without giving up plaintext. If we a

But PFS is specifically about including "my adversary may, at a later date, compromise my private key" in your threat model without giving up plaintext. If we assume that calculating a private key from the public key is ~impossible (which I hope you agree we can do), and we further assume the private key never leaves the device, then forward secrecy is what lets us know the only way to get plaintext is by stealing it from an endpoint. Maybe I'm failing to see the adversary you're defeating with PFS if they're never going to access your device and siphon off private data... I'm no expert, but if all you care about is transit security, I don't think you need PFS (in E2EE messaging! TLS is a different story, because you have to trust the server). Just protect your private key. But if you're carrying multiple device's worth of accumulated messages _right alongside_ your private key, then what's the point of rotating ephemeral keys after each message? EDIT: I agree about a compromise on PFS/chat history being reasonable in most scenarios. But I also think that defaults are really important, especially as the contents of chat history can be leaked by other participants, whose chat backups you can't really control. It's a tough problem to solve for everyone.

darkwater 6y ago
> But PFS is specifically about including "my adversary may, at a later date, compromise my private key" in your threat model I'm no crypto expert but that "later date" when talking about PFS is to avoid an external dragnet recording all your ciphered streams and then deciphering them once they have your non-PFS secret key. I mean, in your definition basically all the messages should be ephemeral on your device and on each recipient device to have PFS.
- KAMSPioneer 6y ago
  I'm comparing two scenarios: In the first, a global adversary (say, NSA) records all your interactions via a chat service. This chat service does not use PFS. At a certain point, they capture the private key from one of your devices that uses the service, and is able to decrypt all your messages. In the second, the same global adversary records all your messages, but this time from an otherwise identical service that DOES use PFS. The adversary captures your private key but can only use it to MitM attack you going forward. However, before discarding your device, they check your conversation history -- because your diligent backup and transfer of all your conversations since you signed up for the chat service, they now have all your messages. PFS did not help. Now, you could change scenario #2 to where you don't have an option to back up and transfer message history (or simply choose not to), and that's essentially Signal. In that case, the adversary is pretty much hosed except for the messages your device just happened to have on it. Adversary steals message backup == adversary steals private key w/o PFS
feanaro 6y ago
> Just protect your private key. This is what PFS is all about: it is about noticing that keeping your private key secret is really hard and admitting you're probably not going to be able to do it. But even so, when it leaks, the attacker won't be able to use it to unlock the ciphertexts of all your previous conversations that he meticulously recorded. This property is PFS. There is no need for the attacker to have access to your device in order to execute this attack against systems which don't have PFS.
- KAMSPioneer 6y ago
  Sorry, I'm probably explaining myself poorly. I much prefer chat systems with PFS because it mitigates the blast radius of a key leak, I get that. What I'm saying is, if you store a message history that contains the plaintext that Mallory wants, and it's stored in the same way the identity key is, PFS doesn't get you much. The attacker who has all your ciphertexts needs the decryption key to get the plaintext (which she wants). Now, with a PFS scheme the key gets deleted as soon as I receive and decrypt the message, so the attacker is out of luck, basically (even if she gets my long-term key). However, PFS only moves the target to my plaintext message database...which is stored the same way my key is (as I understand it). So really, unless I purge my message history with some regularity (I do), then the stakes are the same -- don't let the attacker get access to the device. But most people prefer to have all their chat history available and searchable, at which point individual decryption keys don't matter and therefore PFS doesn't, in my opinion, help much.

darkwater 6y ago

> But PFS is specifically about including "my adversary may, at a later date, compromise my private key" in your threat model I'm no crypto expert but that "later date" when talking about PFS is to avoid an external dragnet recording all your ciphered streams and then deciphering them once they have your non-PFS secret key. I mean, in your definition basically all the messages should be ephemeral on your device and on each recipient device to have PFS.

KAMSPioneer 6y ago
I'm comparing two scenarios: In the first, a global adversary (say, NSA) records all your interactions via a chat service. This chat service does not use PFS. At a certain point, they capture the private key from one of your devices that uses the service, and is able to decrypt all your messages. In the second, the same global adversary records all your messages, but this time from an otherwise identical service that DOES use PFS. The adversary captures your private key but can only use it to MitM attack you going forward. However, before discarding your device, they check your conversation history -- because your diligent backup and transfer of all your conversations since you signed up for the chat service, they now have all your messages. PFS did not help. Now, you could change scenario #2 to where you don't have an option to back up and transfer message history (or simply choose not to), and that's essentially Signal. In that case, the adversary is pretty much hosed except for the messages your device just happened to have on it. Adversary steals message backup == adversary steals private key w/o PFS

feanaro 6y ago

> Just protect your private key. This is what PFS is all about: it is about noticing that keeping your private key secret is really hard and admitting you're probably not going to be able to do it. But even so, when it leaks, the attacker won't be able to use it to unlock the ciphertexts of all your previous conversations that he meticulously recorded. This property is PFS. There is no need for the attacker to have access to your device in order to execute this attack against systems which don't have PFS.

KAMSPioneer 6y ago
Sorry, I'm probably explaining myself poorly. I much prefer chat systems with PFS because it mitigates the blast radius of a key leak, I get that. What I'm saying is, if you store a message history that contains the plaintext that Mallory wants, and it's stored in the same way the identity key is, PFS doesn't get you much. The attacker who has all your ciphertexts needs the decryption key to get the plaintext (which she wants). Now, with a PFS scheme the key gets deleted as soon as I receive and decrypt the message, so the attacker is out of luck, basically (even if she gets my long-term key). However, PFS only moves the target to my plaintext message database...which is stored the same way my key is (as I understand it). So really, unless I purge my message history with some regularity (I do), then the stakes are the same -- don't let the attacker get access to the device. But most people prefer to have all their chat history available and searchable, at which point individual decryption keys don't matter and therefore PFS doesn't, in my opinion, help much.