Session Protocol V2: PFS, Post-Quantum and the Future of Private Messaging

Since its inception, Session has provided a unique offering in the privacy landscape: onion-routing, decentralization, and no phone number requirements. However, Session’s contributors are still listening closely to power users and the broader security community to discover ways in which Session can be further improved. The feedback from the community has consistently focused on a few key areas:

• Session needs Perfect Forward Secrecy (PFS) to better protect historic messages if a device is compromised.

• Session should implement Post-Quantum Cryptography (PQC) to protect messages against an attacker who stores messages now and later breaks traditional cryptographic schemes using a quantum computer.

• Session should implement better visibility of linked devices so users can ensure all  devices linked to their account are properly authorized to read and send messages.

Session contributors have taken this feedback on board and have been working on the designs for an upgrade to the Session Protocol. This upgrade addresses each point raised by the community while maintaining the user experience Session users have come to expect, including:

• Easy multi-device linking and syncing of messages between devices.

• A simple process to recover a Session account using a single Recovery Password if a device is lost.

• Assurance that messages are delivered reliably and remain readable by all authorized linked devices.

Today, we are announcing Session Protocol V2, a proposed upgrade to the Session Protocol which seeks to re-implement forward secrecy, utilizes new Post-Quantum Cryptography (PQC), and delivers improved device management features to ensure better visibility and authorization of linked devices.

The V2 Session Protocol is still undergoing design, and it will take a significant amount of development resources to finalize and integrate into Session. However, we think it is important to signal to the community that this is something the Session Technology Foundation is working on and intends to introduce in the future. Developing this protocol in the open will allow community members, security researchers, and users to give feedback on the proposal, ensuring that the V2 Session Protocol provides maximal security while retaining ease of use.

Before jumping into the goals, objectives, and high-level overview of the protocol, it is important to quickly discuss the current state of the Session Protocol and the high level of security it currently provides.

Session Protocol V1

The current Session Protocol is based around a single Long-Term Key (LTK). The LTK is generated on-device when a user creates a Session account. Each message a user sends is end-to-end encrypted for the LTK of the recipient and decrypted using the recipient's LTK. All devices linked to an account share the same LTK.

This establishes a high level of security for Session users:

• Message contents cannot be read by the decentralized network of Session Nodes that store and relay messages.

• Messages cannot be arbitrarily scraped by other Session users from the network without providing signed authorization from the LTK.

• All messages are onion-routed, hiding the user's IP address and network metadata from the Session Nodes which temporarily store messages; onion routing adds another layer of ephemeral encryption ensuring encrypted messages cannot be scraped by Session Nodes acting as relays in the user's onion request path.

However, the V1 Session Protocol is unable to protect against some highly specific attacks. For example, attackers who are able to run a significant amount of malicious nodes in the Session network and later compromise a Session user's LTK, or attackers who have access to a quantum computer that breaks elliptic curve cryptography, specifically:

• If Session Nodes in a user's swarm are acting maliciously and storing messages beyond their 14-day TTL, and a user's LTK is compromised from their device, then past messages (which previously could not be decrypted) could potentially be decrypted.

• If a post-quantum attacker stores encrypted messages today and later obtains a sufficiently powerful quantum computer, they could decrypt those messages in the future (this is commonly referred to as a “harvest now, decrypt later” attack).

• If a user's device is compromised and an attacker gains access to their LTK, they can link new devices to the user's account without the compromised user having visibility that a new device was linked.

It is important to note that these attacks are not currently practical. Quantum computers capable of breaking traditional elliptic curve cryptography do not yet exist and will likely take many years to develop fully.

Furthermore, an attack on the Session network that involves operating malicious nodes to store messages beyond their 14-day TTL would require significant resources. Each Session Node requires a stake of 25,000 SESH, and an attacker would need to control a substantial portion of the network’s 1,500+ nodes for such an attack to be viable. This attack is further hindered by the fact new nodes are assigned to swarms in a pseudorandom manner, making it difficult for an attacker to place their nodes into specific swarms in order to scrape a particular user’s encrypted messages. Simply storing these encrypted messages does not break a Session user's security; the attacker would also need to target and compromise the user's device and gain access to their LTK to make such stored data useful.

We have not seen any evidence of such attacks on the Session network, but understand the concerns users have raised. These are the attacks the V2 Session Protocol aims to protect against.

Session Protocol V2

Perfect Forward Secrecy

The largest change in the V2 protocol will be the addition of perfect forward secrecy (PFS). As previously discussed, Session Protocol V1 does not achieve forward secrecy currently, as all messages are encrypted under the same LTK; this key does not rotate unless the user creates a new Session account.

Session initially launched with PFS, inherited from the Signal Protocol, but the Signal Protocol was later deprecated in Session due to the significant issues it created for users with multiple linked devices. During the time it was enabled, Session users frequently raised issues with:

• Sent messages not properly syncing between linked devices and remaining in a "failed to decrypt" state.

• Messages received from other users generally failing to decrypt.

• Accounts recovered via the user's Recovery Password not properly recovering message history.

These issues stem from the fact that the Signal Protocol was not designed for use in a decentralized network, and has very limited support for linked devices. To this day, Signal only supports up to five linked devices (one primary mobile device and up to four other linked desktop devices). The Signal Protocol is designed to depend on a centralized server to help clients publish pre-key bundles and keep ratcheting keys in sync between linked devices.

Based on this, it is clear that a new protocol is needed—one that takes cues from the Signal Protocol (still a strong choice in terms of encryption and security) but is designed for a decentralized network (like Session’s) and resolves the challenge of supporting many linked mobile and desktop devices.

The V2 Solution:

Early designs for the Session V2 Protocol introduce a few new concepts to resolve these issues. Instead of relying solely on a permanent LTK for each account to encrypt and decrypt all messages, accounts will establish a set of Rotating Key Pairs for each linked device and a single rotating key pair that is shared across all linked devices on a per-account basis. Per device keys are stored on each device, and the underlying private keys are never shared between linked devices. When a per device key rotates, the old key is deleted after a period of time, meaning if a device is compromised attackers cannot decrypt previously stored messages — as those keys have been rotated and no longer exist. Per-account keys would be kept in sync between linked devices, and these keys would be used by other senders to encrypt messages for your account and, subsequently, all of your linked devices. Per account keys also rotate frequently to ensure an attacker who compromises a device cannot decrypt historic stored messages encrypted by per account keys which are now deleted.

A critical component of the V2 Session Protocol is ensuring that devices remain synchronized as keys rotate, a significant challenge during Session’s previous implementation of PFS using the Signal Protocol. Since then, Session has introduced major infrastructure upgrades, including migrating core cryptographic logic into a shared library called libsession and developing a robust mechanism for synchronizing data across linked devices using "Config Messages". These upgrades, which are already implemented, will serve as the backbone for the V2 protocol and are expected to alleviate the synchronization issues encountered during Session’s previous PFS implementation.

Future-Proofing: Post-Quantum Cryptography (PQC)

As part of the introduction of a new set of rotating keys on a per-device and per-account basis, we have the opportunity to re-select some of the underlying cryptographic algorithms used in Session. This allows us to leverage state-of-the-art in post-quantum cryptography, which has seen significant advancements in recent years, reducing key sizes and performance overheads.

Of particular interest is ML-KEM (previously CRYSTALS-Kyber), a recently standardized post quantum Key Encapsulation Mechanism (KEM). ML-KEM is currently used in several messaging applications, including by Signal (in the Signal Protocol’s PQXDH) and Apple’s PQ3 (used in iMessage).

By utilizing ML-KEM key pairs to establish secure shared secrets in the V2 Session Protocol, we can have higher confidence that messages sent today cannot be retroactively decrypted by future quantum adversaries.

Linked Devices

Adding per-device key pairs into the V2 Session Protocol offers protections against post-quantum attackers and attackers seeking to decrypt stored messages with a compromised LTK, but it also adds a mechanism to increase the visibility of linked devices. Since each device would now have a unique private key which is never shared with other devices, the associated public key can  be used as the basis for a unique identifier for each device. Now when a user has multiple linked devices, they can see the unique identity of each linked device.

Furthermore, when a new device is linked to an account, a user can be shown a notification that a new device was linked. If the user has not linked this device themselves, they can take action to delete their account and messages and abandon potentially compromised hardware in favor of setting up a fresh Session account. This also enables support for future functionality where existing devices must explicitly authorize linking of new devices, preventing a new compromised device from being able to access your Session account in the first place.

The Bottom Line

As previously stated, the V2 Protocol for Session is still under design. Session contributors will be releasing more detailed specifications of the protocol in 2026 as the protocol goes through additional stages of review.

What is clear is that the V2 Session Protocol represents another step forward for Session’s technology stack, building off of Session’s best-in-class anonymity and metadata protection while engineering in further cryptographic assurances, like forward secrecy, and setting the groundwork for post-quantum security and better linked device management capabilities.

If you want to contribute to advancing decentralized messaging and accelerating the development of Session Protocol V2, you can help by donating to the Session Technology Foundation.