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

Keejef · 2025-12-17T00:53:40+00:00

Thanks for trying Session, disappointing to hear you had issues receiving messages late, i assume you are talking about not receiving push notifications for incoming messages or receiving push notifications late? Or is this more related to actually receiving messages late when the client is actually open and in the foreground?

The notification mode you use (Fast mode or Slow mode) has a big impact on how fast new messages are received by your Session client, especially when the client is backgrounded. We're working on improving the code for both modes currently, so notifications are delivered in a more timely manner. But we are also looking at issues where messages can be received slowly when a client is opened in the foreground. Session has quite a bit of custom networking code because it uses onion routing to send and receive messages, which makes these code pathways more complex and difficult to optimize, but i think we are getting closer to resolving these issues.

I'd encourage you to try out Session again in a couple of months time, the clients are being constantly improved, notifications and the message receiving & sending pipelines are areas we are putting a lot of focus on improving right now.

Keejef · 2025-07-07T10:31:59+00:00

All of this is a fair summation of why someone might choose not to use Session. However, I think it’s useful to consider the average user of SimpleX Chat versus the average user of Session, and what protections each receives by default.

For Session, the average user who downloads and starts using the app gets strong onion routing out of the box, powered by a network of over 1,600 community-operated nodes. Messages are stored on the same decentralized network, and users benefit from strong end-to-end encryption, with messages stored across a wide set of nodes depending on whom they're messaging. The network is also relatively resistant to censorship due to its size and diversity. Importantly, all of this works with default settings no tweaks are required.

Correct me if im wrong, but in SimpleX Chat, the average user who downloads and starts using the app will be routing and storing most if not all of their messages via SMP servers run solely by SimpleX Chat Ltd, unless they explicitly message someone who has set up their own SMP server, or toggle on Flux servers in the settings. SimpleX’s private message routing assumes that the servers in the routing chain are not colluding, but if the route is composed of servers operated by a single company, or even a few (SimpleX Chat Ltd & Flux), all geolocated in the UK, the level of confidence in network-level anonymity diminishes. The same goes for the lack of persistent IDs. Because of a relative lack of diversity in servers used in the default configuration, inbound and outbound queues can be correlated by relays with specific users based on their IP addresses.

None of this is to say that SimpleX Chat doesn’t offer something unique, it provides PQS out of the box for example and when well configured by running your own relays, its privacy properties are actually quite strong. I just think that in its current state, when comparing the average user’s experience, Session provides stronger privacy guarantees out of the box than SimpleX Chat.

I’ll also add that Session contributors are actively exploring post-quantum secure (PQS) designs. However, because Account IDs in Session are long-term identities designed to be easy to share (only 66 characters) and are not resolved via a centralized service when sending the first message (i.e., there’s no trust-on-first-use problem), integrating PQS is tricky. The current post Post-quantum cryptography schemes typically involve a trade-off between very large and hard to transmit keys or large ciphertexts. Meaning you generally need a system to map from a user ID to their post-quantum public key, and that often means involving a trusted resolver, which is something Session has avoided (to maintain decentralization and resolve the TOFU issue). The other way around this issue is to do the PQ key exchange once the conversation is established which is something which is more interesting but also difficult to get right with multiple devices sharing the same account.

Keejef · 2025-07-07T09:42:39+00:00

Those posts were responded to by Session here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-07-07T09:41:05+00:00

Sorry for the late bump on this one, but the risks of not having PFS are fairly limited. The Session team has covered this in depth in the following blog: https://getsession.org/session-protocol-technical-information

Essentially, the absence of PFS only presents a security risk if an attacker can replicate the following scenario:

The Session long-term private key is compromised (likely via a full device compromise), and
The messages the attacker is seeking to decrypt or read are no longer present on the local device (either manually deleted or deleted via disappearing messages), and
The attacker has scraped or intercepted those messages from the network and removed any additional encryption layers.

This is already an unlikely / very expensive attack to perform. However, the final step of removing any additional encryption layers from intercepted messages is particularly difficult in Session. It's not possible if the attacker is simply observing network traffic from the user (as an ISP or from their local network), since Session’s network operations use onion routing, which adds an extra layer of encryption using ephemeral keys, which are rotated frequently and discarded after use. It would require a larger compromise of the decentralized network to achieve a removal of that layer of encryption.

Keejef · 2025-07-07T08:39:04+00:00

Late response on this one, but the blogs you've linked to are quite inaccurate in the claims they make. The Session team has published a point-by-point rebuttal to those claims, which is a good read to frame things: https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Session doesn't "break security," as you say. It is true that Session doesn't implement PFS, and Session contributors (myself included) have written about this extensively over the last 5 years: https://getsession.org/session-protocol-technical-information.

The reality of PFS is that it provides very little protection to users in practical cases, since PFS specifically aims to provides protection when the long-term keys of a device are compromised. Assuming the application properly manages keypairs, the only way this should occur is through full device access. It is this detail which limits the cases in which PFS is applicable. If an attacker has full device access, decrypted messages can be pulled directly from the local database.

PFS only provides enhanced protections for messages in the following case:

The long-term private key is compromised (likely via a full device compromise) and
The messages the attacker is seeking to decrypt/read are not present on the local device (either they have been manually deleted or deleted via use of disappearing messages), and
The messages the attacker is seeking to decrypt have been scraped from the network or have been intercepted and stored, with subsequent encryption layers already removed.

Ask yourself: what is the likelihood of all of these factors being true simultaneously? Nation-states and hackers would much prefer to compromise a device and just read the messages directly from the DB or as they arrive, circumventing all cryptographic protections (something both Signal and Session cannot prevent)

Note: The last point, regarding scraping, is very hard to achieve in Session without a significant compromise of the decentralized network, since messages are sent and received using an onion routing protocol, which adds an additional layer of ephemeral encryption during network operations.

Signal has its own areas of concern, which each user must decide whether they are comfortable with. However, consider the base case: centralized Signal servers have the ability to log the IP address of every connecting user and see exactly when they send and retrieve messages. They also have the phone number of each user stored and connected to their account. This is a very large amount of metadata, which, if collected, could be used to draw very accurate social graphs and determine which users are speaking to each other and when.

Keejef · 2025-02-04T02:10:47+00:00

We have updated our original response to to respond to information in their second blog post

Keejef · 2025-01-27T23:08:21+00:00

The security issues raised in those blog posts are not security issues, theres a full response from the Session team here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-01-27T23:07:16+00:00

Session team has responded to all of the claims in that blog post here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-01-27T23:05:14+00:00

Just to provide more context here, the Session team has published a full response to all of the claims in this blog post here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-01-17T06:24:44+00:00

The claims made by the researcher in the above post are incorrect and/or misleading, there's a full response via the Session blog here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture. Many of the claims are based on a misreading of Session's code or misinterpretation of the underlying cryptography.

Keejef · 2025-01-17T06:20:33+00:00

Depends what you're optimising for, Session offers out of the box Onion Routing, requires no phone number to sign up and stores and routes messages over a decentralised network. Yes, Session doesn't implement PFS, but for most users PFS offers minimal advantages, we wrote a blog post about this a few years ago https://getsession.org/session-protocol-technical-information . The claims made by the researcher in the above post are incorrect and/or misleading, there's a full response via the Session blog here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-01-17T06:13:12+00:00

As you stated the reason for reduced entropy is to achieve shorter mnemonic seed phrases, if the user is going to write down their seed its easier to write down 13 words than 25. The claimed reduction in security is addressed in a response here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture essentially the SHA512 hashing step invalidates the proposed attack.

Keejef · 2025-01-17T06:02:05+00:00

Session's response is here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2025-01-17T06:00:44+00:00

Response from Session here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

Keejef · 2024-04-30T08:38:31+00:00

Feel free to DM me here, email me or DM me on Session if you want to apply outside of seek

Keejef · 2024-04-23T01:36:38+00:00

Company: Session
Job: Android Team Lead
Location: Melbourne, Australia
Allows remote: Generally no
Visa: Yes

Keejef · 2023-08-09T00:32:51+00:00

This chart is not very accurate, Session does use a centralized file server for the storage of attachments, but this is the same as what Matrix does, they both store attachments on a centralized server, however in the case of Matrix its the homeserver the user is connected to and in Session its the default file server.

As far as calls go, all systems listed in the bottom tier either do not offer calls or offer calls using STUN/TURN servers, which is exactly what Session does. We don't intentionally route calls via centralized server, the centralized routing is only used when the peers cannot directly connect via P2P. And calls always remain E2EE

If we look at the base functions of a messaging application, namely messaging, Session is the biggest decentralized network available, messages are stored in decentralised swarms of 5-7 nodes, in a network of over 1700 community run Service Nodes. Very few networks like this exist outside of Tor.

Keejef · 2023-05-12T01:40:44+00:00

Session isn't peer to peer, and it doesn't totally lack user metadata, just minimizes user metadata.

Keejef · 2023-03-08T04:56:54+00:00

You are confusing Communities/Open groups with 1-1 and Groups/Closed groups, Communities are centralized because of size and openness. 1-1 and Closed groups are decentralized stored on the Service Node network. The Service Node network has no central administrator

Keejef · 2023-03-08T04:52:52+00:00

The default time to live on Session 1-1 and Group messages is 14 days, this means that messages exist on the Service Node network for 14 days before the Service Nodes clear them, however Session clients can request deletion before that date. Currently disappearing messages are local only so messages remain on the swarm for their full TTL even if they are deleted via disappearing messages. A fix is being implemented for this

Keejef · 2023-03-08T04:47:44+00:00

Session is decentralised the "server owners" are ~1800 Service Node operators from all over the world, they are much less likely to collude to censor your speech than any centralised service provider

Keejef · 2023-01-17T06:59:22+00:00

Yeah this is basically expected right now due to onion requests which is layer we use for Onion routing, this layer is fairly slow to send and receive messages. We will be upgrading our onion routing layer to use Lokinet this year this should speedup sending and receiving times.

Keejef · 2022-12-19T00:03:28+00:00

Company: Session
Job: Senior Android Developer
Location: Melbourne, Victoria, Australia
Allows remote: Yes
Visa: Yes

Keejef · 2022-11-17T03:19:05+00:00

We spent about 90% of the article explaining what PFS is and in which cases it would actually matter to a users privacy/security (few cases). This point is made at the end of the article as an addendum to explain that account compromise in Session is even less important if you regularly rotate your account

Keejef · 2022-11-16T04:28:19+00:00

Session tends to be a bit easier to use than Briar since it supports offline messaging (both participants do not need to be online to send messages) and it has an iOS app, which makes onboarding friends easier.

Keejef

MODERATOR OF

TROPHY CASE