When most people hear "end-to-end encrypted," they imagine a single shared key that both parties use to encrypt and decrypt messages. That model exists — it is what PGP does for email — but it has a serious limitation: if the key is ever exposed, every message encrypted with it is exposed too, in both directions, forever.
The Double Ratchet, designed by Trevor Perrin and Moxie Marlinspike around 2013, solves this by ensuring that every single message uses a different encryption key, and that those keys cannot be reconstructed from each other in either direction. The result is a protocol where a key compromise leaks at most a single message — and recovers automatically once both parties exchange anything new.
Forward Secrecy and Post-Compromise Security
These two properties are easy to confuse. They protect against opposite directions on the timeline.
- Forward secrecy means a key compromise today cannot decrypt messages from yesterday. Past traffic stays safe.
- Post-compromise security (sometimes called future secrecy or self-healing) means a key compromise today cannot decrypt messages from tomorrow, once new key material flows. Future traffic recovers.
Most protocols give you one. TLS 1.3 with ephemeral Diffie-Hellman gives forward secrecy for the session, but if your long-term key is stolen, future sessions are decryptable. PGP gives you neither — the same private key opens every message you have ever received.
The Double Ratchet gives both. The trick is to use two interlocking ratchets running in parallel.
The Symmetric Ratchet: New Key Every Message
The simpler of the two ratchets is a chain of symmetric key derivations. Both parties start with a shared chain key. To encrypt a message, the sender feeds the chain key into a KDF — typically HKDF — to produce two outputs: a fresh message key for this message, and a new chain key for the next.
The crucial property is one-way: given a chain key, you can produce all future message keys, but given a message key, you cannot work backwards to recover the chain key. So if an attacker steals your message key for message #42, they can decrypt that one message and nothing else. Once it is used, your device deletes it.
The name "ratchet" comes from mechanics: a gear that turns one way and cannot turn back. Each symmetric derivation steps the chain forward irreversibly. The state moves; the history is unrecoverable.
This alone gives forward secrecy: a key stolen at message #42 leaves messages #1 through #41 safe, because their keys were destroyed long ago.
What it does not give is post-compromise security. If an attacker steals the chain key itself, they can derive every future message key. The chain has no way to "heal."
The Diffie-Hellman Ratchet: New Shared Secret Per Round Trip
The second ratchet runs on top of the first and provides the healing. Every time a party sends a message, they include a fresh ephemeral Diffie-Hellman public key in the header. When the other party receives it, they combine it with their own latest DH private key to produce a fresh shared secret — and they mix that secret into their chain key.
The next time they send a message, they generate a new DH key pair of their own, attach the public key, and the cycle repeats. Each round trip injects fresh randomness sampled on a different device into the key schedule.
Consider what this means for an attacker who has stolen your current chain key. As soon as a new DH ratchet step happens — typically the next message in either direction — the chain key is replaced by a value derived from a fresh ephemeral private key the attacker does not have. Their access window closes. Subsequent messages are again unreadable to them.
This is the post-compromise security guarantee. It does not require detection of the compromise or any action from the user. It happens automatically as a side effect of normal messaging.
Putting It Together: How a Single Message Flows
To send a message in an established Double Ratchet session, the sender's code does roughly this:
- If this is the first message of a new "sending chain" (i.e. the previous message was inbound), generate a new DH key pair and derive a new root key + sending chain key from the latest DH shared secret.
- Derive a message key from the current sending chain key, advancing the chain.
- Encrypt the plaintext with the message key (typically AES-256 in CBC or GCM mode, with HMAC-SHA256 authentication).
- Send the ciphertext along with the current DH public key and a counter indicating message position in the chain.
The receiver does the inverse: if the incoming DH public key is new, run a DH ratchet step to derive a new receiving chain; then derive message keys forward in the chain until they reach the counter on the incoming message; decrypt; delete the used message key.
Out-of-Order and Lost Messages
Real networks deliver messages out of order, drop them, or duplicate them. The Double Ratchet handles this with a small skipped-message keys cache. If message #42 arrives before message #41, the receiver derives keys for #41 and #42, decrypts #42, and stores #41's key in a bounded cache to wait for the delayed message.
The cache has a hard size and time limit so that an attacker cannot force unbounded memory growth by simply never delivering certain messages. Signal's reference implementation uses a default of 1000 cached skipped keys, with old ones deleted as new ones arrive.
What the Double Ratchet Does Not Solve
For all its elegance, the Double Ratchet is only one piece of a complete messaging protocol. It assumes you already have a shared initial root key with the other party — typically established by Signal's X3DH key agreement, which uses long-term identity keys and pre-published one-time keys to bootstrap a session even if the recipient is offline.
It also does not handle groups. Group chats need a different construction, because pairwise Double Ratchets between every member scale poorly and don't agree on a shared state. This is the problem MLS (RFC 9420) was designed to solve, and it is why Haven uses MLS for group messaging and a Double Ratchet construction only for 1:1 fallback.
| Property | PGP | TLS 1.3 | Double Ratchet |
|---|---|---|---|
| Forward secrecy | ✗ | ✓ (per session) | ✓ (per message) |
| Post-compromise security | ✗ | ✗ | ✓ |
| Async (recipient offline) | ✓ | ✗ | ✓ (with X3DH) |
| Group messaging | awkward | ✗ | use MLS |
Identity Verification Is Still Your Job
The Double Ratchet protects you against passive eavesdroppers and against an attacker who steals key material at one point in time. It does not protect you against an active attacker who controls the channel from the beginning of the session and feeds each side a different identity key.
This is why Signal, WhatsApp, and Haven all support safety number or fingerprint verification — comparing a hash of both parties' long-term identity keys through some out-of-band channel. TOFU (trust on first use) is the common default, but it only works if the first use was not already compromised.
Why This Algorithm Won
The Double Ratchet was not the first attempt to combine forward secrecy with key continuity. OTR (Off-the-Record) Messaging, from 2004, pioneered the idea of using ephemeral DH keys for forward secrecy in chat. But OTR was synchronous and didn't handle offline recipients well, which made it unsuitable for mobile messaging.
The Double Ratchet's contribution was making the construction work asynchronously, with no requirement that both parties be online at once, and with bounded state. That made it practical for the mobile-first messaging era, which is why it ended up inside the most-used encrypted apps in the world.
The specification is published openly. The Signal Protocol documentation contains the full algorithm with test vectors, and multiple independent implementations exist in Rust, Java, Swift, and C++. The combination of strong properties, public specification, and broad real-world deployment is a rare thing in cryptography. It is worth understanding even if you never implement it yourself, because the threat model it addresses is the one every modern messenger must claim to address.