The Signal Protocol: The Encryption Behind Two Billion Conversations

Every message you send on WhatsApp, every text on Google Messages RCS, every chat on Signal, and as of December 2023, every personal message on Facebook Messenger uses the same underlying cryptographic design. It is called the Signal Protocol, and it protects more conversations than any other end-to-end encryption scheme ever deployed.

The protocol was designed by Moxie Marlinspike and Trevor Perrin at Open Whisper Systems between 2013 and 2016. It solves a problem that had frustrated cryptographers for decades: how do you give two people a private, authenticated, forward-secret conversation when they might never be online at the same time, when messages might arrive out of order, and when either person's device might be compromised at any point during the exchange?

What follows covers the full protocol stack, from initial key exchange to per-message encryption. The diagrams are interactive; drag nodes to explore the relationships.

A Brief History

The protocol traces back to 2010, when Marlinspike co-founded Whisper Systems (with Stuart Anderson) and released TextSecure, an encrypted SMS app for Android. Twitter acquired Whisper Systems in 2011, and Marlinspike subsequently open-sourced TextSecure. In 2013, he founded Open Whisper Systems to continue development.

The critical innovation came in 2013-2014 with the TextSecure V2 protocol, which introduced the "Axolotl Ratchet" (later renamed the Double Ratchet). This replaced the earlier OTR-influenced design with something fundamentally new: a ratcheting construction that provided both forward secrecy and post-compromise security.

In November 2015, TextSecure and RedPhone (Whisper Systems' encrypted voice app) merged into Signal on Android. The iOS app had been available since 2014. The protocol specifications were formally published in November 2016: X3DH (Extended Triple Diffie-Hellman) for key agreement, and the Double Ratchet Algorithm for ongoing message encryption.

WhatsApp integrated the Signal Protocol in April 2016, bringing end-to-end encryption to over one billion users overnight. It remains the largest single deployment of end-to-end encryption in history. Google Messages adopted it for RCS conversations in 2020-2021. Facebook Messenger rolled out default end-to-end encryption for all personal messages in December 2023 after a multi-year infrastructure rebuild.

In February 2018, Brian Acton, co-founder of WhatsApp, provided a $50 million loan to establish the Signal Foundation as a 501(c)(3) nonprofit. Marlinspike stepped down as CEO in January 2022. After an interim period with Acton serving as acting CEO, Meredith Whittaker took over as president of the Signal Foundation.

The Key Types

The Signal Protocol uses five categories of keys, each with a different lifetime and purpose. All asymmetric keys use Curve25519.

Identity Key Pair. Generated once at registration and kept for the lifetime of the account. This is your cryptographic identity. Your public identity key is published to the server and is the basis for "safety number" verification, the process where two users compare a hash of their identity keys to confirm they are talking to each other and not a man-in-the-middle.

Signed Prekey. A medium-term key pair, rotated roughly every one to four weeks. It is signed by your identity key so that anyone fetching it can verify it really belongs to you. Old signed prekeys are kept for a grace period to handle messages that were encrypted against the previous key but haven't arrived yet.

One-Time Prekeys. Ephemeral key pairs uploaded to the server in batches, typically 100 at a time. Each one is used exactly once and then permanently deleted. They provide an extra layer of forward secrecy for the very first message in a conversation.

Ephemeral Key Pair. Generated fresh by the conversation initiator for each new session. Used only during the initial key exchange and then discarded.

Ratchet Keys, Root Keys, Chain Keys, Message Keys. These are the symmetric and asymmetric keys that evolve during the conversation. Ratchet key pairs (Curve25519) change with each conversational turn. Root keys, chain keys, and message keys are 256-bit symmetric keys that advance irreversibly with every message. A message key encrypts exactly one message and is immediately deleted.

X3DH: Starting a Conversation When Nobody's Home

The first challenge the protocol solves is asynchronous key exchange. Alice wants to send an encrypted message to Bob, but Bob is offline. His phone is in his pocket, or off, or on airplane mode. He cannot participate in a real-time handshake.

This is where X3DH (Extended Triple Diffie-Hellman) comes in. Bob pre-uploads key material to the server before he goes offline, and Alice uses that key material to establish a shared secret without Bob needing to do anything until he eventually picks up his phone.

The sequence works like this.

Bob's setup (registration and ongoing). Bob's client generates an identity key pair, a signed prekey pair (signing the public portion with the identity key), and a batch of one-time prekey pairs. All the public halves go to the server. The server now holds a "prekey bundle" for Bob.

Alice initiates. Alice's client fetches Bob's prekey bundle from the server: his identity key, his current signed prekey (with signature), and one of his one-time prekeys (if any are available). Alice verifies the signature on the signed prekey using Bob's identity key. If it fails, she aborts. If it succeeds, she generates a fresh ephemeral key pair and computes four Diffie-Hellman operations:

• DH1 = DH(Alice's Identity Key, Bob's Signed Prekey). This proves Alice's long-term identity is involved. If Alice's ephemeral key were compromised but her identity key were not, the secret would still hold.
• DH2 = DH(Alice's Ephemeral Key, Bob's Identity Key). This proves Bob's long-term identity is involved. It protects against compromise of Bob's signed prekey alone.
• DH3 = DH(Alice's Ephemeral Key, Bob's Signed Prekey). The core exchange. Fresh randomness from Alice combined with Bob's medium-term key.
• DH4 = DH(Alice's Ephemeral Key, Bob's One-Time Prekey). The one-time prekey bonus. Even if Bob's signed prekey is later compromised, this session is protected because the one-time prekey's private half was deleted after use.

The four DH outputs are concatenated and run through HKDF (HMAC-based Key Derivation Function using SHA-256) to produce the initial shared secret. If no one-time prekey was available, DH4 is simply omitted, and the shared secret is derived from three DH outputs instead of four. The protocol still works, but with slightly reduced forward secrecy for the initial message. That forward secrecy is fully restored as soon as Bob replies and the Double Ratchet performs its first step.

Alice sends Bob her identity key, her ephemeral key, an identifier for which of Bob's keys she used, and the first message encrypted under the derived secret. When Bob eventually comes online, he loads the corresponding private keys, performs the same DH computations in reverse, derives the same shared secret, and decrypts.

The Double Ratchet: Forward Secrecy for Every Single Message

X3DH establishes the initial shared secret. The Double Ratchet takes over from there, providing two properties that no static encryption scheme can offer:

Forward secrecy. Compromise of current keys cannot decrypt past messages. Every message is encrypted with a unique key that is deleted immediately after use.

Post-compromise security (self-healing). Even if an attacker temporarily compromises a device's full key state, the protocol automatically recovers. As soon as a new round-trip of messages occurs, fresh cryptographic material is introduced that the attacker cannot derive.

The protocol achieves this by combining two interlocking ratchet mechanisms.

The DH ratchet (asymmetric). Each time the direction of conversation changes (Alice sends, then Bob replies, then Alice sends again), the active sender generates a new Curve25519 key pair and includes the public key in the message header. The recipient performs a DH with their current private ratchet key and the sender's new public key. The result is mixed into the root chain via HKDF to produce a new root key and a new chain key. This is the "big step" that introduces fresh entropy and provides post-compromise security.

The symmetric ratchet (hash ratchet). Between DH steps (when one person sends multiple messages in a row), a simpler HMAC-based chain advances the keys:

Chain Key[n+1] = HMAC-SHA256(Chain Key[n], 0x02) Message Key[n] = HMAC-SHA256(Chain Key[n], 0x01)

Each message key encrypts exactly one message and is then deleted. Each chain key is replaced by the next and deleted. Because the HMAC is a one-way function, you cannot go backwards from Chain Key[n+1] to Chain Key[n]. This gives per-message forward secrecy even within a single sending chain.

The overall flow: the root chain sits at the top, fed by DH ratchet outputs. It spawns sending and receiving chains. Each chain spawns individual message keys. Keys only ever flow downward, and every key is deleted after use.

Out-of-Order Messages

Network conditions mean messages don't always arrive in order. The protocol handles this cleanly. Each message header includes a message number (its position in the current sending chain) and the length of the previous chain. If a receiver gets message #5 before message #3, they advance the chain to position 5, store the skipped message keys for positions 3 and 4 in a buffer, and decrypt message #5 immediately. When message #3 eventually arrives, they look up the stored key and decrypt it.

Stored keys are capped at a configurable maximum (preventing memory exhaustion attacks) and deleted after use or after a timeout. It is a bounded trade-off: you accept a small window of stored keys in exchange for reliable decryption of reordered messages.

The Cryptographic Primitives

The primitive choices are conservative, favoring battle-tested constructions over newer alternatives:

Curve25519 for all Diffie-Hellman operations. Designed by Daniel J. Bernstein, it provides roughly 128-bit security with 32-byte keys. Chosen for speed, constant-time implementation, and resistance to timing side channels.

AES-256-CBC with HMAC-SHA256 in an encrypt-then-MAC construction for message encryption. The message key is split via HKDF into an encryption key, a MAC key, and an IV.

HKDF (RFC 5869) with SHA-256 for all key derivation. Used in X3DH for the initial secret, in the root chain KDF, and for splitting message keys into encryption components.

XEdDSA for signatures. This is a scheme designed by Trevor Perrin that allows a Curve25519 key pair (which is a Diffie-Hellman key, not a signing key) to produce EdDSA-compatible signatures. It works by exploiting the birational equivalence between the Montgomery form (Curve25519) and the twisted Edwards form (Ed25519). This avoids the need to maintain two separate key pairs per user, one for DH and one for signing.

In September 2023, Signal deployed PQXDH, a hybrid post-quantum upgrade to X3DH that adds a CRYSTALS-Kyber (ML-KEM) key encapsulation on top of the existing Curve25519 exchange. The shared secret is derived from both the classical DH outputs and the post-quantum KEM output, so security holds even if either primitive is broken.

Multi-Device and Session Management

The Sesame protocol, also designed by Marlinspike and Perrin, handles the complexity of multiple devices. In Signal's model, each device (phone, desktop, iPad) has its own identity key, signed prekeys, and one-time prekeys. Messages are encrypted separately for each of the recipient's devices using independent Double Ratchet sessions.

The server operates a simple mailbox model: encrypted messages are stored per-device and delivered when the device comes online. The server sees ciphertext blobs and routing metadata, nothing else. If both Alice and Bob simultaneously initiate sessions to each other (a race condition), Sesame resolves which session to use by selecting the most recently active one.

Signal also implements sealed sender, which encrypts the sender's identity inside the message envelope so that the server can route the message to the recipient but cannot see who sent it. The sender includes a "sender certificate" (issued and signed by the Signal server) inside the encrypted payload. The recipient decrypts the outer layer to discover the sender, then decrypts the inner Double Ratchet message. This provides sender anonymity from the server, though not from the recipient.

What the Server Knows (and Doesn't)

The Signal server:

Does know: That Alice sent a message to Bob. When. How large. Which devices. That Bob read it (delivery receipts, if enabled).

Does not know: The contents of any message. The decryption keys. Alice's identity when sealed sender is used (it sees only the recipient).

Cannot do (even if compromised): Decrypt past messages. Forge messages that pass authentication. Insert itself into an existing session without being detected (safety number verification catches this).

Can do (if compromised or malicious): Withhold messages (denial of service). Withhold one-time prekeys (forcing reduced forward secrecy). Attempt key substitution attacks (detectable through safety number changes). Collect metadata about communication patterns.

The protocol is explicitly designed with an untrusted server in mind. The server is a dumb pipe with a mailbox. The security properties hold even if the server is fully adversarial, with the exception of metadata.

libsignal: The Implementation

Signal's official implementation is libsignal, an open-source library with a Rust core and bindings for Java (Android via JNI), Swift (iOS via C FFI), and TypeScript (Node.js via NAPI). The Rust core ensures a single auditable codebase for all cryptographic logic across platforms.

The library is licensed under AGPL-3.0, which requires any service providing its functionality over a network to release source code. This is deliberately restrictive. WhatsApp, for instance, built their own implementation of the protocol (in collaboration with Open Whisper Systems) rather than using libsignal directly.

Developers integrating libsignal implement a ProtocolStore interface for persisting session state, prekeys, identity keys, and sender keys. The library handles all protocol logic: X3DH session establishment, Double Ratchet message encryption and decryption, and group operations.

Formal Verification

The protocol has been through multiple independent formal analyses:

Cohn-Gordon et al. (2017, Journal of Cryptology 2020) provided a formal security proof using the Tamarin prover, a tool for automated reasoning about security protocols. They found the protocol sound but noted reduced security guarantees when one-time prekeys are exhausted. This was published at IEEE Euro S&P 2017.

Alwen, Coretti, and Dodis (EUROCRYPT 2019) provided a comprehensive modular security analysis of the Double Ratchet, formalizing its guarantees in a composable framework. Their analysis treats the DH ratchet and symmetric ratchet as independent modules that compose to provide the full security properties.

Frosch et al. (2016) performed an early analysis of the TextSecure V2 protocol, identifying some theoretical concerns about authentication ordering but finding the overall design sound.

Cohn-Gordon et al. (2016) formalized the notion of post-compromise security itself, using Signal's Double Ratchet as a primary example of a protocol achieving this property.

No practical attacks against the core protocol have been demonstrated. The known limitations are architectural rather than cryptographic: trust-on-first-use for identity keys (mitigated by safety number verification), metadata visibility to the server (mitigated by sealed sender), and the fundamental impossibility of protecting against a fully compromised endpoint.

MLS: The Group Messaging Evolution

The Signal Protocol was designed for one-to-one conversations. Group messaging was added later using Sender Keys: each group member maintains a symmetric ratchet for sending, and distributes the sender key to other members via pairwise Signal Protocol sessions. This works, but adding or removing a member requires O(n) pairwise operations, which becomes expensive for large groups.

MLS (Messaging Layer Security), published as IETF RFC 9420 in July 2023, addresses this with a tree-based key agreement structure called TreeKEM. Each group member is a leaf in a binary tree. Updating key material requires only O(log n) encryptions (updating the path from leaf to root) instead of O(n). For a 1,000-person group, that is roughly 10 operations instead of 1,000.

MLS provides the same forward secrecy and post-compromise security as the Signal Protocol, but scales to groups that would be impractical with pairwise ratcheting. Cisco Webex has implemented MLS for encrypted meetings. The Matrix protocol is exploring it as a successor to Megolm. Signal itself has not announced MLS adoption, though they have engaged with the standard. (Apple's iMessage PQ3, while also post-quantum, uses a Signal-style ratchet with CRYSTALS-Kyber rather than MLS.)

MLS is not a replacement for the Signal Protocol. It is a complement, designed for the group scenario where the Signal Protocol's pairwise approach hits its scaling limits. For one-to-one conversations, the Double Ratchet remains hard to improve on.

Why It Matters

Most cryptographic protocols live in one of two worlds: academically rigorous but impractical, or widely deployed but theoretically shaky. The Signal Protocol sits in both. It has formal security proofs published in top cryptography venues. It also runs on billions of devices, handles unreliable networks, supports multiple devices per user, and recovers gracefully from every failure mode short of a fully compromised endpoint.

The core insight, that a conversation's encryption should continuously evolve, introducing fresh randomness and destroying old keys, is what separates it from earlier approaches like PGP (which uses a single static key pair for everything) or basic TLS (which provides forward secrecy per-session but not per-message).

The protocol's biggest remaining challenge is metadata. The Signal Foundation knows who is talking to whom and when, even if they cannot read the contents. Sealed sender mitigates this, but does not eliminate it. Fully metadata-resistant messaging remains an open research problem, and solving it at Signal's scale will likely require fundamental changes to how messages are routed.

For now, though, the Signal Protocol represents the best answer anyone has found to the question of how to give two people a private conversation over an untrusted network. Compromising today's keys gives you exactly today's messages and nothing else. Tomorrow, the ratchet turns.

The protocol specifications are published at signal.org/docs. libsignal source code is at github.com/signalapp/libsignal. The X3DH spec (Marlinspike, Perrin, 2016) and Double Ratchet spec (Perrin, Marlinspike, 2016) are available as PDFs on the Signal website. Formal analysis: Cohn-Gordon et al. in the Journal of Cryptology (2020) and Alwen, Coretti, Dodis at EUROCRYPT 2019.