Perfect forward secrecy

[slrslr]

"Session does not support perfect forward secrecy, which is when an encryption system automatically and frequently changes the keys it uses to encrypt and decrypt information, such that if the latest key is compromised it exposes a smaller portion of sensitive information."
Source: https://www.privacyguides.org/real-time-communication/#session

"Does the app enforce perfect forward secrecy? No"
Source: https://www.securemessagingapps.com

Maybe Session does not collect significant amount of "sensitive information", yet can it be improved by having perfect forward secrecy?

https://www.perfectforwardsecrecy.com/index.php
https://www.signal.org/blog/asynchronous-security/

[beantaco]

I don't have a good understanding of the technical tradeoff, but in what appears to be for ease of decentralisation, the Session team (unfortunately) decided to drop forward secrecy.

"Using existing long-term keypairs in place of the Signal protocol massively simplifies 1-1 messaging."

Furthermore, they believe forward secrecy is effective only in theory, and justify the decision to drop forward secrecy with "fully anonymous account creation, onion routing, and metadata minimisation" among the mitigations.

https://getsession.org/blog/session-protocol-explained
https://getsession.org/blog/session-protocol-technical-information
(December 2020)

To compensate for loss of forward secrecy, I guess the Session team is therefore relying on Session users to re-create and re-share their Session IDs on a frequent basis. In my opinion this is a burden on users and in practice most Session users won't do it.

I see the following ways forward:

• Introduce forward secrecy into Session Protocol.
• Add a feature that guides the user through the process of conveniently re-creating and re-sharing (selectively perhaps) a new Session ID in such a way that the process is secure and users don't lose the ability to contact each other.

[KeeJef]

We don't have any current plans to reintroduce PFS, the articles linked above cover our view on the issue. We will be looking at making it easier to rotate accounts as a whole

[slrslr]

"There is no reason why physical access to a device should mean total access to messages that were deleted previously; all serious secure messaging protocols today use forward secrecy to limit the impact of device compromise.

Furthermore, most modern (eg, designed in the last decade or so) protocols also provide post-compromise security (aka “backward secrecy”, “future secrecy”, or “self-healing”) to introduce new entropy into their ratchets such that when a device is temporarily compromised (as is actually very often the case in real-world attacks on mobile operating systems) the key material which an attacker can exfiltrate doesn’t allow them to decrypt future messages which are sent later after the device is uncompromised (eg, rebooted)."