How Does End-to-End Encryption Actually Work?

In 2013, a journalist in Hong Kong handed a stranger a laptop and asked him to read the files on it. The stranger was Glenn Greenwald, the files were Edward Snowden’s, and the lesson that travelled around the world with that story was blunt: if someone else holds the keys to your messages, your messages are not really yours. Within a few years, the world’s biggest messaging apps had rebuilt themselves around a different promise — that not even the company running the service could read what you sent. That promise has a name: end-to-end encryption. The phrase gets printed on splash screens and in privacy policies, but the machinery behind it is rarely explained. This guide opens it up.

A locked box with two keys

Start with the oldest idea in the system: the locked box.

Imagine you want to send a letter to a friend, and you both own padlocks, but you have never met. You cannot hand your friend a key without someone intercepting it along the way. The classic solution, worked out by Whitfield Diffie and Martin Hellman in 1976, is a trick of mathematics: each of you generates a pair of keys that are linked. One is public — you can shout it across a crowded room. The other is private and never leaves your device. Combine your private key with your friend’s public key, and you both arrive at the same secret number. Anyone watching the exchange sees only the public keys, and from those alone, the secret cannot be reconstructed. That is a Diffie-Hellman exchange, and it is the first brick in every modern encrypted messenger.

A single shared secret, though, is not enough for real conversations. People are offline. Phones get stolen. Messages arrive out of order. The protocol that solved all of that at once is called the Signal Protocol, developed from 2013 by Open Whisper Systems (now the Signal Foundation). It powers Signal itself, WhatsApp, Google Messages over RCS, and Skype’s private conversations — billions of messages a day. Understanding it means understanding three pieces: the handshake, the ratchet, and the check.

The handshake that works while you sleep

Most older secure systems needed both people online at the same time to agree on a secret. That fails for messaging, where you routinely text someone who is asleep, on a plane, or simply not looking at their phone. The Signal Protocol’s answer is the Extended Triple Diffie-Hellman handshake, X3DH for short.

Here is how it works in plain terms. When you install the app, your phone quietly uploads a bundle of public keys to the company’s server: a long-term identity key that says “this is me,” a signed prekey that rotates regularly, and a stack of one-time prekeys, each meant to be used once and then thrown away. The server stores these and nothing else — no private keys, no message content.

When your friend wants to message you for the first time, her phone fetches your bundle from the server and performs several Diffie-Hellman exchanges at once: her identity key against your signed prekey, her fresh one-time key against your identity key, and her fresh key against your signed prekey — plus, if one is available, against one of your one-time prekeys. The results are mixed together through a key derivation function, a one-way mathematical blender that turns the combined secret into the session’s starting key. The multiple exchanges matter because each one proves something different: the ones involving identity keys prove both sides are who they claim to be, while the ones involving fresh, throwaway keys mean that even if someone later steals a long-term key, they cannot rewind and decrypt this first exchange.

Your friend can now encrypt her first message and send it. The server passes the sealed envelope along. When you wake up and open the app, your phone runs the same mathematics from its side and arrives at the same starting key. Neither of you was online at the same moment, and the server never held anything that could open the envelope.

A new key for every single message

The handshake gets the conversation started. The ratchet keeps it safe.

A ratchet is a mechanism that turns in one direction only. The Signal Protocol’s Double Ratchet uses two of them, interlocked. The first is the symmetric-key ratchet: for every message you send, your phone feeds the current chain key through a one-way function and out come two things — the key that encrypts that one message, and the next chain key. The old chain key is deleted. Because the function runs one way, someone who steals today’s chain key cannot run it backwards to recover yesterday’s messages. That property is called forward secrecy, and it is the reason a single stolen key does not unlock a whole conversation history.

The second ratchet is the Diffie-Hellman ratchet, and it is what makes the system heal. Every time the direction of conversation changes, each side generates a fresh Diffie-Hellman key pair and sends the new public key along with the message. The receiver combines it with their own latest private key, producing a brand-new shared secret that gets mixed into the chain. Suppose an attacker somehow copies your phone’s entire encryption state today. They can read messages until the next round trip — and then the fresh Diffie-Hellman secret, generated after the theft, locks them out again. Security people call this post-compromise security. In plainer language: the conversation recovers on its own.

Underneath all of this, the actual scrambling of message text is done by a symmetric cipher — in Signal’s case, AES with 256-bit keys, paired with a message authentication code that proves the message was not tampered with in transit. The public keys themselves are small: Signal uses the X25519 curve, where each public key is just 32 bytes. Small keys, short messages, and a server that stores nothing sensitive are why this works on cheap phones and slow networks, not only on powerful computers.

How do you know nobody is in the middle?

Mathematics can keep a server out, but it cannot by itself prove that the “friend” at the other end is really your friend. An attacker who controlled the server could hand you a fake key bundle and sit in the middle, decrypting and re-encrypting everything. The protocol’s defence is deliberately low-tech: verification.

Each conversation has a safety number (sometimes shown as a QR code) derived from both participants’ identity keys. If you and your friend compare those numbers — in person, over a phone call, through another channel — and they match, no one is sitting between you. If one of you reinstalls the app or switches phones, the identity key changes, the safety number changes, and the app warns you. Many people ignore these warnings. They are the one part of the system that depends on human behaviour rather than mathematics, and they are worth paying attention to.

What end-to-end encryption does not do

A locked conversation still leaves footprints around the edges, and honest guides should say so.

First, encryption protects content, not metadata. The server that relays your messages can usually still see who you messaged, when, and how often — even if it cannot read a word. That pattern of contact can itself be revealing. Second, encryption protects messages in transit, not on the device. Anyone holding your unlocked phone can read your chats, and anyone who can compel you to unlock it does not need to break any mathematics. Third, backups are a separate decision from messaging. If your chat backup is stored in plain text on a cloud drive, the strength of the messenger’s encryption no longer matters for those messages. Some apps now offer encrypted backups; if yours does, turning that on closes a hole most people never notice. Finally, encryption cannot verify that the person typing is the person you think they are — only that the device holding the keys is the one you verified earlier.

The quantum question

There is one more shadow on the horizon, and the protocol’s designers have already started answering it. The Diffie-Hellman exchanges at the heart of the system depend on a mathematical problem that a large enough quantum computer could solve, which would let a future attacker decrypt messages recorded today. In 2023, Signal added PQXDH, a version of the handshake that mixes in a post-quantum key exchange (based on ML-KEM, a lattice-based standard) alongside the classical one, so session setup resists that future attack. In 2025, work began on extending similar protection to the ongoing ratchet itself. Nothing about this changes what you do as a user. It is a reminder that encryption is maintenance, not a one-time achievement: the locks get re-cut as the tools for picking them improve.

Why this matters

The reason end-to-end encryption spread from activists and journalists to billions of ordinary users is not that billions of people have secrets worth stealing. It is that a messaging system where the operator cannot read the messages changes the balance of power in a quiet but fundamental way. A government order, a company data breach, or a rogue employee cannot expose what was never stored in readable form. The trade-offs are real — the same property that protects a journalist’s sources also frustrates investigators chasing criminals, and that argument will run for years. But the mechanism itself is no longer mysterious. A handshake that works while you sleep, a fresh key for every message, and a number you can check with your own eyes: that is what stands between your words and everyone except the person you sent them to.

What happens next

Expect the invisible parts to keep changing while the visible parts stay boring, which is exactly how it should be. Post-quantum protection will spread from session setup into the ratchet, and from Signal into the other apps that use its protocol. The visible check — the safety number, the verification warning — will remain the human half of the system, and it will keep depending on whether people bother to use it. If you take one habit from this guide, make it this: when an app warns you that a contact’s safety number has changed, do not tap through it on autopilot. Ask why it changed. That single question is the last line of a system designed, from the ground up, to need no trust in anyone except the person at the other end.

Sources

• Signal Foundation, Signal Protocol documentation: https://signal.org/docs/
• Signal Foundation, X3DH key agreement specification: https://signal.org/docs/specifications/x3dh/
• Signal Foundation, Double Ratchet specification: https://signal.org/docs/specifications/doubleratchet/