Session Protocol v2: An Update on PFS, Post-Quantum and Linked Devices

In December 2025, Session's developers announced Session Protocol v2: a proposed upgrade bringing perfect forward secrecy (PFS), post-quantum cryptography (PQC) and better linked device management to Session. At the time, the protocol was still in early design.

Ten months later, much of Protocol v2 is implemented. The protocol now has a public specification, core encryption is implemented in libsession and the first groundwork is already shipping in Session clients. Below is an overview of what has changed since the original announcement, what is still being designed and how to support its development.

Where Protocol v2 stands today

The original announcement committed to releasing more detailed specifications in 2026. That specification is now public on GitHub, and development is publicly visible in libsession, the shared library that handles Session's core cryptography across iOS, Android and Desktop.

PFS and post-quantum encryption for one-to-one messages: Implemented (libsession #90, April 2026)

Device linking with on-screen verification: Implemented (libsession #90, April 2026)

Device groups (joining, removal and membership): In progress (libsession #187, October 2026)

Forward compatibility in current apps: Shipped in iOS 2.15.5, Android 1.33.6 and Desktop 1.18.2 (session-desktop #2025, session-ios #808, session-android #2232, October 2026)

Migration plan for existing accounts: In design.

Current versions of Session can already recognize messages sent in the Protocol v2 format. Instead of dropping them, the app shows a placeholder asking you to update Session and keeps the message so it can be read once you do. This will let v2 roll out gradually, without messages disappearing for anyone still on an older version.

Perfect forward secrecy for a decentralized network

Conventional approaches to PFS, including the Signal Protocol Session originally used, depend on centralized infrastructure to publish keys and keep linked devices in sync. Session has no central server, so Protocol v2 is a new design built specifically for a decentralized network.

The original proposal outlined the basic idea: rotating keys per device and per account, instead of a single permanent key. The specification now details how this will work:

Account and device keys will rotate roughly every 12 hours. Any of the linked device will calculate its own randomized rotation time, to minimize devices from colliding and obscures how many devices an account has.

Old keys will be forgotten after 16 days. That covers Session's 14-day swarm message storage lifetime plus a safety buffer, so offline devices will still be able to read messages waiting for them, and nothing older will remain decryptable.

Private keys will be shared between linked devices through encrypted device group data, never through the long-term account key. This means compromising the long-term key alone will not be enough to recover past message keys.

Public keys will be published to the network for contacts to fetch, and refreshed regularly, replacing the role a central key server plays in other designs.

In v1, an attacker who stored encrypted messages and later compromised a device could potentially decrypt that history. With v2, the keys protecting that history will no longer exist. A removed device, or a device that has its encryption broken and keys cloned, has only a limited window before the device group rotates to new keys that cannot be read. Even a complete clone of a device will not be able to remain in the device group undetected: either the clone would be excluded the next time the real device rotates its keys, or the clone would itself rotate and real device would very visibly notice that it has been excluded, warning the user about the potential compromise.

Post-quantum protection

ML-KEM, the post-quantum standard used by Signal and Apple's iMessage, was originally identified as the leading candidate for Protocol v2. That choice is confirmed, and v2 will use ML-KEM as part of a hybrid design.

Each account will publish two keys, an ML-KEM-768 key and an X25519 key, and every message will be encrypted using a secret derived from both. This follows the X-Wing construction, a published scheme for combining traditional and post-quantum key exchange. The published keys are updated approximately every 12h by any of an account's devices and are retrieved automatically from the recipient's swarm when composing a message.

X25519 is the well-tested elliptic curve cryptography Session already uses, while ML-KEM is designed to resist attacks from quantum computers. An attacker would need to break both to decrypt a v2 message, so messages stay protected as long as either one holds.

This is designed to address "harvest now, decrypt later" attacks, where an adversary stores encrypted messages today in the hope of decrypting them once quantum computers are powerful enough.

Linked devices

The Protocol v2 proposal set out two goals for linked devices: showing users every device linked to their account and notifying them when a new one is added. Requiring existing devices to approve new ones was listed as possible "future functionality."

Device approval is now part of the core design:

Linking will require confirmation on both devices. When you link a new device, both screens will show a short set of distinct emoji, and you will confirm they match on each device before the link completes. This sequence offers the user assurance that they are linking the correct device; it is designed to be difficult enough to compute that forging it (for example: watching a swarm for a device link request and then quickly replacing it with an alternate keys that produces the same emoji sequence) is infeasible during the device linking window.

Each device will have its own identity. Devices will be listed individually with a short description, so you will be able to see exactly what devices have access to your messages.

Removing a device will rotate the account keys. A removed device will lose access to new messages, and will only be able to return by being linked again (with user confirmation) into the linked devices.

Impersonation is detectable. If another device takes over an existing device's identity, Session will detect it if the rogue device rotates device keys (and alert the user) or will rotate the device keys itself and leave the rogue device behind.

The transition to Protocol v2

Because Session users run many different devices and app versions, the transition will be gradual:

v2 will switch on automatically. When your app finds v2 keys published for a contact, it will use v2 encryption for messages to them. No settings will need to change.

A fallback will keep older contacts reachable. If a contact hasn't upgraded yet, or if a contact has not been online in a very long time, messages will fall back to the current protocol, and Session will indicate when a message was sent or received with weaker security.

A grace period of at least six months will keep v1 compatibility while everyone updates.

A graceful fallback for accounts without published PFS/PQ keys will be used after the v1 grace period that encrypts using just the basic Session ID encryption, similar to current v1 encryption, but externally indistinguishable from fully encrypted PFS messages. (This fallback is only used when contacting an account that has been offline for more than a month and whose published PFS/PQ keys have expired from their swarm.)

Notifications will keep working. The design includes a way for iOS and Android to fetch new keys when a notification arrives, so messages encrypted with a freshly rotated key will still show up.

The migration process for existing accounts is still being designed. An account can only switch to v2 once all of its linked devices support it. Because v1 doesn't keep track of linked devices, users may need to confirm this step manually. More details will be shared as this is finalized.

Plans are also being explored to release an early alpha of Protocol v2 as a separate, invite-only app for early testing. These testers would get to use PFS for direct messages and help find issues before it reaches the main Session app.

PFS will apply only when both people in a conversation are using the v2 alpha. The alpha would run alongside the current Session app, with non-PFS message history from the past 14 days staying synced between the two. After testing in the alpha and, later, by the wider community in a beta phase, PFS and PQ will be integrated into the main Session app.

Protocol v2, Session Router and the Session Network

Protocol v2 upgrades Session's end-to-end message encryption, and parallel work is underway on the network layer that carries those messages. An upcoming deep dive will cover those changes in detail. Session Router is set to become the main transport for Protocol v2, and every connection it establishes will use PFS and post-quantum encryption, adding another layer of protection as messages travel across the network. It will also cover the efficiency and storage improvements made to oxen-core, storage server and Session Router, the software that powers Session Nodes.

What's next

With the core cryptography implemented, the remaining work includes integrating Protocol v2 into the Session apps, finishing device group management, finalizing the migration plan and putting the protocol through further review before release.

Completing this work requires funding. Session has been selected for Octant's Epoch 13 Privacy Round, which runs from October 14 to 21. The round uses "quadratic funding" for reward matching, wherre the number of distinct people who contribute matters more than the total size of contributions. Every supporter, even with small donations, increases Session's share of the 100 ETH matching pool.

Funds raised in this round will go toward completing Session Protocol v2 and releasing it to users. Support Session on Octant.

As always, v2 is being developed in the open. Security researchers and community members can follow along and give feedback on GitHub.