The Session Protocol: What’s changing — and why

Note: This article provides a non-technical overview of what the Session Protocol will achieve, and why we’re introducing it. For a more detailed, highly technical explanation of the Session Protocol, check out our technical deep dive. 

One of the most vital steps when setting out to build a private messenger is threat assessment. In order to determine which features should be prioritised, developers need to understand how and when each feature will be beneficial to you — the user. 

As an example of this type of process, we can take a look at a specific example of threat assessment being employed. Any messaging application needs to decide how (or if) messages will be protected from prying eyes. The simplest way to transmit messages is in plaintext (in other words, not encrypted) — it’s easy to implement and work with, but any third party that can access the messages while they’re in transit or at any other point will be able to read them, so if you’re after security, this option is out. 

One step up from there is encryption in transit and at rest, where messages are encrypted in transit between devices, but are decrypted upon reaching the server that routes them. This method provides protection against unauthorised parties accessing the messages in transit, but still allows for anyone with access to the central server to read the contents of every message, along with viewing metadata associated with a message, including information about the sender and recipient. If such a threat is important to protect against, it’s necessary to go another step further — end-to-end encryption. 

If you’ve spent any time reading about private messengers, you’ve probably heard of E2EE before. E2EE means that only the sender and the recipient have the means to decrypt messages. Neither the central message-routing server nor any third parties who intercept messages in transit can see the contents of an E2EE message. Many applications don’t use end-to-end encryption, either because of the additional development costs to implement or because they want central servers to have access to user messages — it’s all down to developers’ threat assessments, and the protections and mitigations they decide to implement.

Companies or projects that want the highest degree of privacy and security for their users will often consider implementing a decentralised infrastructure for their app or service — with no central servers whatsoever, users don’t have to worry about trusting the entity running the network at all.

Mission: Possible — Session Protocol

In Session’s case, our analysis has led us to a conclusion: the features we think will be most important for our users are best served by migrating Session to its own encryption protocol — the Session Protocol. 

The Signal Protocol is great at what it does, and what it does is security — a whole lot of it. Session does security too, but the problem is that Session’s scope also includes a focus on anonymity and decentralisation. Now that Session is well-established and we’re working to add features, one issue keeps cropping up: the Signal Protocol simply wasn’t built to work this way. It was built to operate in a centralised environment, and we’ve been trying to shoehorn it into Session’s starkly different infrastructure.  That’s where the Session Protocol comes in. This new protocol will let us improve stability and streamline the development of new features. Of course, nothing in life comes easy, and there are a few features that won’t join us on the next leg of this adventure. However, the benefits of the Session Protocol make this transition well worth it. 

PFS and deniable encryption: Effective protection… in theory 

First things first, let’s talk about what we’re leaving behind: Perfect Forward Secrecy (PFS) and deniability. For more information about these properties, you can check out our technical deep-dive on the differences between the Signal and Session protocols, but read on for an abbreviated overview.

PFS means that if long-term keys for a given conversation are compromised, only a small amount of recent messages can be decrypted. However, under typical circumstances, the only way long term keys can be compromised is through full physical device access — in which case an attacker could simply pull the already-decrypted messages from the local database.  As is often said in the infosec community, physical access is total access.

Cryptographic deniability, or deniable authentication, prevents either party in a conversation from proving the origin of any message to a third party — essentially, Alice can’t cryptographically prove to anyone outside the conversation that Bob was the one who sent a specific message. The problem is that practical applications for deniability are very limited. Court rulings and media reporting both commonly ignore deniability and defer to evidence of the conversation taken directly from the device — like screenshots. One example of deniability as an unsuccessful defense was in the case of the communications between Chelsea Manning and Adrian Lamo.

Session’s mitigations

The simple fact of the matter is that Session provides protections against these types of threats in other ways — through fully anonymous account creation, onion routing, and metadata minimisation, for example. These protections will prove as effective, or more so, in many real-world scenarios within Session’s scope and threat model.

We believe the new possibilities and significantly streamlined encryption pipeline introduced by the Session Protocol make these tradeoffs well worth it for our users. 

In addition, Session will be introducing a new feature to mitigate edge-case risks associated with message retrieval. Session messages are temporarily stored on specific “swarms” of 5-7 nodes, from which they can be retrieved by a Session client if the client is offline at the time a message is sent (and thus unable to receive the message in real-time). We will be implementing long term key-based signature checks into this retrieval process as an additional layer of security to prevent any device or client besides the intended recipient from retrieving messages being held in temporary storage on swarms. Because messages remain fully encrypted while in swarm storage, such a risk is extremely minimal even under the current implementation. However, we want to make Session as secure and private as possible, which means taking steps to mitigate risk wherever possible, all while building a messenger with high levels of functionality and ease of use. 

Party rockin’ with the Session Protocol

Now the fun part: the benefits of this new protocol. First off, simplicity — we built it, we know the ins and outs, and we can build on it to create the features you want (and need). The switch will also fix some bugs relating to the way key pairs are exchanged in the Signal Protocol (once again, for more information visit this deep-dive).

Multi-device is one key feature that the Session Protocol will let us implement (or re-implement, in this case). We’ve had a hell of a time trying to cram a decentralised multi-device implementation into the Signal protocol, but try as we might, it just wouldn’t fit. Now that we have our own protocol, we can streamline the process and reimplement multi-device much more easily. Account restorations will also be made much more reliable. 

The most important feature of this new protocol is that it is purpose-built for Session. The Signal protocol was exactly what we needed when starting out, but as Session has grown, it has become clear that it requires a protocol designed for a decentralised platform. 

The Session Protocol:  A win for devs and users alike

When assessing threats and practical ways to mitigate them, ranking both threats and mitigations is a vital step. Our transition to the Session Protocol comes down to the types of protections we believe will be most meaningful in the real world to the majority of our users. We believe that anonymity and decentralisation can provide strong protection against censorship, privacy infringement, and other threats. We want to optimise Session to solve these wider issues — and the Session Protocol is the best way to do that.