3 ms·

I mean, from the perspective of the crypto it doesn't matter. But it defeats the point of building a forward-secret system. Think of it like this: if I'm an at

• upofadown 6y ago
  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.
• dwohnitmok 6y ago
  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.
  • KAMSPioneer 6y ago
    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.
      • 6y ago
• fsflover 6y ago
  > 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.
• smichel17 6y ago
  > 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 https://signal.org/docs/specifications/x3dh/#deniability