When you send the first message in a new Signal or WhatsApp conversation, something slightly magical happens: your phone encrypts a message to a person who may be asleep, on a plane, or have their device powered off — and that person can later decrypt it. There was no live handshake. No back-and-forth. Yet both ends end up holding the same secret key, and no one watching the network learned it.
The mechanism is X3DH — Extended Triple Diffie-Hellman — a key agreement protocol published by Signal's Moxie Marlinspike and Trevor Perrin in 2016. It solves the asynchronous problem that plain Diffie-Hellman can't, and it produces the seed that the Double Ratchet then grows into a full conversation's worth of keys.
The Problem: Diffie-Hellman Needs Both Sides Present
A standard Diffie-Hellman exchange is a conversation. Alice sends a public value, Bob sends one back, and each combines the other's value with their own private key to compute a shared secret. It's elegant, and it gives you a fresh key that an eavesdropper can't reconstruct. But it has a hard requirement: both parties have to be online to exchange those values.
Messaging breaks that assumption constantly. The whole point is to fire off a message and walk away. So Signal needed a way for Alice to do a Diffie-Hellman exchange with Bob without Bob being there — and still get mutual authentication (proof she's really talking to Bob) and forward secrecy (so a future key compromise doesn't unlock today's messages).
The Fix: Bob Leaves Keys on the Shelf
X3DH works because Bob does his half of the handshake in advance. When Bob installs the app and registers, his device uploads a bundle of public keys to the server and goes about its day. The server holds these like a stack of pre-addressed envelopes. Bob's bundle contains three kinds of key:
- Identity key (IKB) — long-term, tied to Bob's account. This is what "being Bob" cryptographically means.
- Signed prekey (SPKB) — a medium-term key, signed by Bob's identity key so its authenticity can be verified. Rotated periodically (Signal rotates it on the order of days to weeks).
- One-time prekeys (OPKB) — a batch of single-use keys. The server hands out one per new conversation and never reuses it.
When Alice wants to message Bob, she fetches one of these bundles. She does not need Bob to be online — the server speaks for him. She verifies the signature on the signed prekey using Bob's identity key (this is the authentication step; a malicious server can't substitute its own prekey without breaking the signature). Then she generates a fresh ephemeral key (EKA) for this exchange.
Why "Triple" (Plus One)
The name comes from the Diffie-Hellman computations Alice performs. Each DH(X, Y) below mixes one of Alice's private keys with one of Bob's public keys — and because DH is symmetric, Bob can later compute the identical values from his side once he comes online and sees which prekeys Alice used.
| Computation | What it binds together | Property it provides |
|---|---|---|
| DH1 = DH(IKA, SPKB) | Alice's identity ↔ Bob's signed prekey | Authenticates Alice to Bob |
| DH2 = DH(EKA, IKB) | Alice's ephemeral ↔ Bob's identity | Authenticates Bob to Alice |
| DH3 = DH(EKA, SPKB) | Alice's ephemeral ↔ Bob's signed prekey | Forward secrecy |
| DH4 = DH(EKA, OPKB) | Alice's ephemeral ↔ Bob's one-time prekey | Extra forward secrecy / replay resistance |
The final shared secret is derived by concatenating these results and running them through a key derivation function: SK = KDF(DH1 ‖ DH2 ‖ DH3 ‖ DH4). DH4 is optional — if the server has run out of Bob's one-time prekeys, X3DH proceeds with just the first three. That's the "triple"; the one-time prekey is the bonus fourth that strengthens the result when available.
Each DH alone would be enough to produce a secret. Combining them is what gives X3DH its properties simultaneously: the identity keys provide authentication, the ephemeral key provides forward secrecy, and the one-time prekey ensures that even if Bob's signed prekey is later compromised, the sessions that used a one-time key stay protected. No single key compromise unravels everything.
What Each Key Is Actually Protecting Against
The design is easier to appreciate as a set of answers to specific attacks:
- A malicious server swapping keys — defeated by the identity key signing the signed prekey. Alice checks that signature before trusting anything.
- An attacker who records traffic now and steals keys later — defeated by the ephemeral key, which is generated fresh and deleted after use. Forward secrecy means yesterday's recordings stay opaque.
- Replay of the first message — mitigated by one-time prekeys. Because each is used once and then discarded by the server, an attacker can't replay the same handshake to get Bob to re-derive the same key.
- Prekey exhaustion — the signed prekey is the fallback. Sessions that fall back to three-DH mode are slightly weaker against one specific replay scenario, which is why apps refill the one-time prekey pool aggressively.
After the Handshake: Handing Off to the Ratchet
X3DH's job ends the moment SK exists. It's a one-shot protocol — it establishes the initial shared secret and then steps aside. That secret becomes the root key for the Double Ratchet algorithm, which takes over and generates a new key for every single message, healing from compromise as the conversation continues.
This two-stage structure is worth noting: X3DH gets you a secure start, the Double Ratchet keeps you secure over time. Together they're the core of what's loosely called the Signal Protocol, and the same pairing underlies WhatsApp, Google Messages' encrypted mode, and others.
The Curves and the Post-Quantum Successor
In practice the DH operations use Curve25519 (X25519), and the prekey signatures use XEdDSA, a scheme that lets the same Curve25519 identity key be used for both key agreement and signing. The KDF is HKDF. None of this is exotic — it's the same well-reviewed primitives used across modern cryptography.
The one thing X3DH does not defend against is a future quantum computer capable of breaking elliptic-curve Diffie-Hellman. An adversary recording handshakes today could, in that hypothetical future, recompute the shared secrets. Signal's answer is PQXDH, deployed in 2023, which adds a post-quantum key encapsulation (Kyber/ML-KEM) alongside the classical X3DH so that breaking the session requires breaking both the elliptic-curve and the lattice-based component. If you want the broader context on that shift, see our piece on post-quantum cryptography.
Why This Design Keeps Getting Copied
X3DH endures because it solves a genuinely hard problem cleanly: asynchronous, authenticated, forward-secret key agreement with no trusted third party beyond a dumb mailbox server. The server stores public prekeys and hands them out; it never sees a private key and can't decrypt anything. Compromising it leaks metadata, not message contents.
That's the property worth internalizing whenever you evaluate a secure messenger. "End-to-end encrypted" is table stakes. The harder questions are how the first key gets established, whether that step authenticates both parties, and whether the server could quietly insert itself. X3DH answers all three — which is why, a decade on, it's still the template.