X3DH (Extended Triple Diffie-Hellman)

X3DH, short for Extended Triple Diffie-Hellman, is the key-agreement protocol that lets two parties establish a shared secret even when one of them is offline. This asynchronous property is what makes encrypted messaging practical: you can send a first message to a contact who is asleep with their phone off, and they derive the same key when they wake up. It is the handshake that precedes the per-message ratcheting of a live session — the bootstrap that turns two strangers' published keys into a private channel.

Prekeys and the offline bootstrap

The protocol works by having each user publish a bundle of public keys to a server in advance. That bundle contains a long-term identity key, a medium-term signed prekey (rotated periodically and signed by the identity key), and a batch of single-use one-time prekeys. A sender fetches a recipient's bundle, verifies the signature, generates an ephemeral key pair, and computes the shared secret immediately, without the recipient being present. In effect, the recipient has pre-answered the handshake: the prekeys are their half of a conversation they have not yet joined. The server merely stores and serves public key material — it never holds anything secret.

Three (or four) Diffie-Hellman computations

X3DH performs three DH computations, or four when a one-time prekey is available, then feeds them through a KDF to produce the session secret. Two of the computations bind the parties' identity keys to provide mutual authentication; the others mix in ephemeral and prekey material to provide forward secrecy. Crucially, authentication is achieved through Diffie-Hellman rather than digital signatures over the transcript, which gives the protocol cryptographic deniability: neither party can later present a portable proof that the other participated in the conversation. For a sovereign user, that is a deliberate feature — your messages authenticate to your counterparty in the moment without becoming signed evidence against either of you afterward.

What the server can and cannot do

The trust analysis is instructive. A malicious server cannot read messages or forge identities — it holds only public material. What it can do is refuse service, log who fetched whose bundle (metadata), or exhaust the one-time prekeys so sessions fall back to the slightly weaker three-DH mode. The residual risk that matters is identity-key substitution: a server could hand you an impostor's bundle, which is exactly why serious messengers surface safety numbers or QR-code verification so users can confirm identity keys out of band. Verify once, and the server has no further avenue into your channel's contents.

Where it fits and where it's going

The prekey model does place one operational duty on users: bundles must be replenished. A device that stays offline for months may see its one-time prekeys exhausted, and identity keys change when a device is reinstalled — which is why messengers warn that a contact's safety number has changed. Treat that warning as the protocol working, not failing: it is the one moment X3DH asks a human to re-verify before trusting the channel again. A quick out-of-band check with the contact restores the authenticated channel and defeats the substitution attack the warning exists to catch.

X3DH produces the shared secret consumed by the Double Ratchet Algorithm, and the pair form the cryptographic core of the Signal Protocol — the design that made strong end-to-end encryption the default expectation for private messaging. The design continues to evolve: Signal's successor handshake, PQXDH, augments the same structure with a post-quantum key-encapsulation step so that recorded traffic cannot be decrypted by a future quantum computer. The architecture lesson travels well beyond messaging: publish public material in advance, authenticate through key agreement, and no third party ever needs to be trusted with a secret.