Chat history isn't immediately at odds with PFS. As I see it PFS first and foremost is for protecting messages in transit. This is to prevent dragnet-style surveillance.

Chat history means giving up some measure of at-rest security, but it has no impact on the in transit part. Personally I also think some compromise of at-rest is a reasonable trade-off for a lot of consumer contexts because physical capture of your device already is basically game over.

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.

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

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

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

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.

> you have kept a perfect record of every conversation you've ever had

The other side of this coin is deniability. If you break into my secure location and steal my chat logs, but you can't tell which are real and which are fake, you've still got work to do.

The Signal protocol has you covered, here. After the fact (ie, as long as you don't watch me receive the message), there is no way to cryptographically prove which of the two participants wrote the message[0]. Thus, it is technically possible to forge a bunch of chat history, or claim that someone else's is forged. Cryptographically, the "spirit of forward secrecy" is secure.

That said, this is far out of the reach of the average person. Even if the only evidence is a screenshot, that conversation probably happened. So in practice yes, you've got a point. That's why I think it would really behoove Signal to add a "forge a conversation" feature. Make it trivial for either person to add a message to their local history that looks like it came from any of the participants, at a specific date/time. Now you've got practical deniability, too.

[0] https://signal.org/docs/specifications/x3dh/#deniability

The way I like to think about it:

If you had a way to keep your old messages safe then you could of just used that method to protect your private key.

> But it defeats the point of building a forward-secret system.

Such thinking defeats the actual purpose of the program: to serve users. I don’t want to delete at least some of my history. It’s like Windows, which know better than the users what they want.