← Lesson 1 of 1
Advanced 30 min read

The Double Ratchet

Every message you send on Signal or WhatsApp is encrypted with a key that's used once and then destroyed, and the keys themselves keep evolving as the conversation goes back and forth. The design behind this is called the Double Ratchet. It's famously hard to picture, so this lesson builds it up one piece at a time, then lets you run the real thing.

What a messenger needs

A website connection with ECDHE lasts seconds and both sides are online. A chat is different. It can last for years, the other person is often offline, and phones get lost, stolen, seized or infected. Trevor Perrin and Moxie Marlinspike designed the Double Ratchet for Signal in 2013 with two goals beyond plain encryption:

GoalThe question it answersHow the ratchet achieves it
Forward secrecyIf my keys are stolen today, are my old messages safe?Every message key is derived one-way and deleted after use.
Post-compromise securityIf my keys are stolen today, will my future messages become safe again?New Diffie–Hellman randomness is mixed in every time the conversation changes direction.

Post-compromise security is the unusual one. It's also called “self-healing”: an attacker who copies your keys once gets locked out again after a short time, without you even knowing they were there. A ratchet is a mechanism that only turns one way, and the Double Ratchet uses two kinds.

Ratchet one: hash chains

Start with a single secret called a chain key. To send a message, run it through a one-way function (here, HMAC-SHA-256) twice with different labels. One output is a message key, used to encrypt this one message. The other becomes the next chain key. Then delete the old chain key and the message key.

HMAC HMAC HMAC … HMAC HMAC HMAC used, deleted used, deleted current next Chain key 1 Chain key 2 Chain key 3 Chain key 4 Message key 1 Message key 2 Message key 3 encrypted message 1 encrypted message 2 encrypts message 3
Each turn of the chain derives a message key and the next chain key, then deletes the old ones. Every arrow is one-way: nothing leads back from chain key 3 to keys 1 or 2.

Because the function is one-way, you can step forwards along the chain but never back. Someone who steals chain key 3 can't work out message keys 1 or 2. That's forward secrecy. But they can step forwards as far as they like.

Try it Turn a chain, then steal it

These keys are real HMAC-SHA-256 outputs. Each coloured square is drawn from a key's bytes, so equal keys always look the same.

That's the flaw in a hash chain alone: it never heals. Once Eve has the chain key, she can follow it forever, because nothing new ever enters it. Fixing that needs fresh randomness that Eve doesn't have.

Ratchet two: fresh Diffie–Hellman keys

The fresh randomness comes from Diffie–Hellman. Each side has a current ratchet key pair, and every message carries its sender's current ratchet public key in its header.

Whenever the conversation changes direction, the person replying makes a brand new ratchet key pair. Combining their new private key with the other side's latest public key gives a new Diffie–Hellman output that nobody else can compute. It's like a game of ping-pong: each time the ball crosses the net, it carries new randomness with it.

Alice’s keys Shared secrets Bob’s keys Eve copies A1 A1 A2 A3 B1 B2 B3 S1 S2 S3 S4 S5 Eve locked out from here →
Alice speaks, using her newest key Bob speaks, using his newest key Eve reads this chain only from the theft onwards Eve reads this whole chain
Read left to right. Alice opens with A1 and Bob's prekey B1, giving S1. Bob replies with a new key B2, giving S2. Alice replies with a new key A2, giving S3, and so on. This assumes Eve copies Alice's keys once, while A1 is still current, and then only listens.

Each new secret shares one key with the previous step and replaces the other. Suppose Eve copies Alice's keys while A1 is current. S1 is already in use, and it was mixed with a root key Eve never had, so the copy gives her Alice's current chain only from the moment of theft. Her earlier messages stay safe. S2 is worse: Eve holds A1's private key and the current root key, so she can follow Bob's entire reply chain. But S3 uses A2, a private key Alice generated after the theft. Eve has never seen it, so she's locked out, and so is every secret after it.

One caveat: this healing assumes Eve only listens. With Alice's stolen keys, an active attacker could pose as Alice towards Bob and slip in ratchet keys of her own, keeping a foothold. That's much harder to do unnoticed, because the real Alice's messages would start failing, but it's why a stolen phone is still serious.

Putting the two ratchets together

Running a full Diffie–Hellman exchange for every single message would work, but it would be slow and would need both people online. The Double Ratchet combines the two ideas. Each person keeps three chains:

  1. A root chain A long-lived secret that both sides share. Each new Diffie–Hellman output is mixed into it, and each time it turns, it produces the starting key for a new sending or receiving chain.
  2. A sending chain A hash chain that turns once for every message you send in a row.
  3. A receiving chain A hash chain that turns once for every message you receive in a row. Your receiving chain is always an exact copy of the other person's sending chain.
DH secret 1 DH secret 2 DH secret 3 Root key … KDF KDF KDF msg key 1 msg key 2 msg key 3 Alice → Bob msg key 1 msg key 2 Bob → Alice msg key 1 msg key 2 Alice → Bob
Alice’s sending chain (Bob’s receiving chain) Bob’s sending chain (Alice’s receiving chain)
Each new Diffie–Hellman secret turns the root chain once and starts a fresh message chain. Circles are chain keys; each one produces a message key and the next chain key. The chains alternate direction as the conversation goes back and forth.

Consecutive messages in one direction only turn the hash chain, which is cheap and works while the other side is offline. When the direction changes, the receiver sees a new ratchet public key in the header and performs a DH ratchet step. It mixes the new secret into the root chain to get a fresh receiving chain, makes a new ratchet key pair of its own, and turns the root chain again to start its own fresh sending chain.

The simulator

This is the Double Ratchet algorithm as Signal specifies it, running on your browser's built-in cryptography: P-256 Diffie–Hellman, HKDF for the root chain, HMAC-SHA-256 for the message chains and AES-GCM for the messages themselves. Messages wait in the network lane until you deliver them, in any order you like.

Try it Alice, Bob and the Double Ratchet
Things to try
    Eve, the attacker Eve can see every message in the network lane, but not its contents. Let her steal one side’s keys at any moment.
    What just happened

      Watch the colours. Alice's sending chain key matches Bob's receiving chain key whenever Bob has caught up with her messages, and vice versa. The root keys, though, almost never match: whoever received most recently has already turned the root chain one extra step to start their own new sending chain, so the two sides stay exactly one turn apart. The ratchet key on each message header shows which sending chain it belongs to, and it changes only when its sender has heard from the other side.

      Late and lost messages

      Real networks deliver messages late, out of order or not at all. Each header carries two numbers to cope with that: N, the message's position in its sending chain, and PN, how many messages the sender sent in their previous chain.

      • If message 3 arrives before message 2, the receiver turns its chain past position 2, stores message key 2 for later, and uses key 3. When message 2 turns up, the stored key decrypts it and is then deleted.
      • If a message arrives with a new ratchet key, PN tells the receiver how many messages from the old chain it might still be waiting for, so it can store those keys before switching chains.
      • Stored keys are a small exception to forward secrecy: they sit on the device until their message arrives. Implementations cap how many they'll store, and delete them after a while, so a malicious sender can't make them store millions.

      What a break-in gets Eve

      Pulling it together, here's what Eve gets from one snapshot of Alice's keys. Test yourself before checking with the simulator's “Steal Alice's keys now” button.

      Quiz Eve copies Alice’s phone once. Can she read…

      How a conversation starts

      The ratchet needs a shared secret to begin with, and Bob may be offline when Alice first writes. Signal solves this with a key agreement protocol originally called X3DH. Bob uploads a bundle of public keys, called prekeys, to the server in advance. Alice downloads Bob's bundle, runs several Diffie–Hellman calculations combining her keys with his, and gets a shared secret she can start ratcheting with straight away. Bob computes the same secret when her first message arrives. One of Bob's prekeys also serves as his first ratchet public key, which is why, in the simulator, Bob can't send anything until Alice's first message reaches him.

      In 2023 Signal upgraded this to PQXDH, which adds a post-quantum key encapsulation (ML-KEM) to the initial agreement. Signal has since been adding post-quantum protection to the ratchet itself, so that both the start of a conversation and its ongoing healing resist future quantum computers. See the post-quantum lesson for why that matters.

      What it can't do

      • An attacker who stays. Healing only works if Eve copies the keys once and leaves. Malware that remains on the phone simply reads each message as it's decrypted.
      • Messages stored on the device. The ratchet protects messages in transit. Your chat history on the phone, and any cloud backup, are protected only by the phone's own security.
      • Who you're talking to. If Eve swaps keys at the very start, the ratchet runs perfectly between you and Eve. Comparing safety numbers checks that the keys really belong to your contact, the same problem certificates solve for websites.
      • Metadata. The server still sees who messages whom, and when. Signal adds separate techniques to hide some of this, but the ratchet itself doesn't.

      Why this matters

      • Every message gets its own key. Hash chains derive one per message and delete it, so stolen keys can't unlock the past.
      • Every change of direction adds fresh randomness. New Diffie–Hellman keys feed the root chain, so a thief who copied keys once is locked out after a round trip.
      • The two ratchets need each other. Hash chains are cheap and work offline; Diffie–Hellman steps heal. Together they give forward secrecy and post-compromise security.
      • It protects billions of conversations. Signal, WhatsApp and several other messengers use the Double Ratchet or close variants of it.