Part III · 3 — End-to-end messaging (Signal)
In TLS, you trust the server. In end-to-end messaging, you do not: not even the server that delivers the messages should be able to read them. The Signal protocol solves this — and even gives guarantees that TLS does not: recovery after compromise and plausible deniability.
3.1 What changes: end-to-end
In the client-server model (TLS), the message is decrypted at the server. For chat, that is unacceptable: the server is precisely who must not read. E2EE (end-to-end encryption) encrypts at the origin and only decrypts at the final destination — the server sees only opaque traffic that it routes.
The challenge: the two ends are rarely online at the same time, and the conversation lasts months. This requires two properties beyond those of TLS:
- Forward secrecy — compromising today's key does not reveal past
messages (as in TLS).
- Post-compromise security (PCS) — if the state is compromised today, the
security recovers on its own in the next messages. TLS, with its fixed session key, does not have this.
3.2 X3DH: the asynchronous handshake
X3DH (Extended Triple Diffie-Hellman) solves the problem of combining a secret when one of the ends is offline. Each user publishes on the server a set of public keys (identity + pre-signed keys + a batch of one-time keys). Whoever starts the conversation downloads that bundle and combines the initial secret by doing several Diffie-Hellmans between the keys — without the other needing to be online. The server only stores and delivers public keys; it never sees the secret.
3.3 The Double Ratchet
Once the initial secret is established, the Double Ratchet generates a new key for every message — hence the name "ratchet": it only advances, never goes back.
It combines two mechanisms:
- Symmetric ratchet (KDF) — for each message, a KDF derives the next key
from the previous one and discards the old one. It gives fine forward secrecy: the key for each message dies after use.
- Diffie-Hellman ratchet — periodically, the parties exchange new ephemeral
keys and mix a fresh DH into the chain. This is what gives PCS: even if an attacker has captured the state, the next DH evicts them.
The result: compromising one key reveals, at most, one message — not the conversation.
3.4 Plausible deniability
A desirable effect of the MAC-based construction (and not a signature-based one): the recipient cannot prove to third parties that a message came from the sender, because they themselves had the symmetric key to forge it. Each one knows the message is authentic; no outsider can prove it. It is the opposite of non-repudiation — and desired in private conversations.
3.5 The full picture
End-to-end messaging stitches together everything in the compendium:
| Guarantee | Mechanism | Part |
|---|---|---|
| Combine a secret offline | X3DH (several DHs) | II — asymmetric |
| Message confidentiality | AEAD | II — symmetric |
| Forward secrecy | symmetric ratchet (KDF) | II — hash/KDF |
| Post-compromise security | DH ratchet | II — asymmetric |
| Authenticity without non-repudiation | MAC | I — goals |
Koder relevance: this is the reference standard for any private-message feature in the Stack (see ktalk's north star as the primary surface). E2EE is not "stronger TLS" — it is a different trust model, in which not even the infrastructure itself is trusted.
Dense reference: the detail of X3DH, the Double Ratchet, sealed sender, and the Noise framework is in
07-protocols. End of Part III — the primitives are choreographed. Part IV — Post-quantum (under construction) confronts what changes when the quantum computer breaks the asymmetric foundations of all this.