What “end to end” means
The ends are the devices of the people communicating. In end-to-end encryption, the sender’s device encrypts a message before it leaves, and only the recipients’ devices hold the keys to decrypt it. Everything in between, such as the app’s servers, an internet relay, a Wi-Fi network or another phone passing the message along, handles only ciphertext.
Apple’s description of iMessage is a typical statement of the goal: message content and attachments are secured with end-to-end encryption so that no one but the sender and receiver can access them, and Apple cannot decrypt the data. The IETF’s Messaging Layer Security standard opens the same way, describing end-to-end security as making messages accessible only to the communicating endpoints, not to the servers that deliver them.
How it differs from encryption in transit
Encryption in transit protects data while it moves between two machines. TLS 1.3, which secures web and app connections, lets a client and a server communicate in a way designed to prevent eavesdropping, tampering and forgery. But the server is one of the two ends of that connection, so it decrypts everything it receives. If a message goes from your phone to a chat server over TLS and on to your friend over another TLS connection, the server sees it in the clear in the middle.
| Kind of encryption | Who can read the content |
|---|---|
| In transit (TLS) | Each server the data reaches |
| At rest on a server | The service, which holds the storage keys |
| End to end | Only the sender and the intended recipients |
Data stored on a server is often encrypted too, but with keys the service holds. Apple’s Advanced Data Protection for iCloud shows the difference: when a user turns it on, service keys that were held in hardware security modules in Apple’s data centres are deleted there and kept only on the user’s trusted devices, which is what makes that data end-to-end encrypted.
End-to-end encryption does not replace TLS. Apps usually use both: TLS protects each connection, and end-to-end encryption protects the content across all of them.
How it works
End-to-end encryption rests on public and private keys. Each device has a key pair and keeps the private half to itself. To send a message, the sender’s device needs the recipient’s public key. The two devices use their keys to agree on a shared secret, derive symmetric keys from it, and encrypt each message with authenticated encryption, which also detects tampering.
Two practical problems follow.
- Recipients are often offline. Signal’s X3DH specification solves this with prekeys: the recipient publishes public keys to a server ahead of time, and a sender can use them to set up an encrypted session and send a first message while the recipient is away.
- You have to know the key is really theirs. A service usually runs a directory that maps phone numbers or usernames to public keys; iMessage registers each device’s public keys with Apple’s identity service. A directory that lies could hand out its own key instead. X3DH notes that unless people compare key fingerprints, for example by scanning a QR code, they get no cryptographic guarantee of who they are talking to.
When there is no server at all, devices exchange and verify keys directly. How does end-to-end encryption work when there is no server? covers that case.
Groups and changing keys
Encrypting for one recipient is the easy case. For a group, every member needs the current keys, and the group changes as people join and leave. MLS, published as RFC 9420, is the IETF’s standard for this: it establishes group keys asynchronously, with forward secrecy and post-compromise security, for groups ranging from two members to thousands. How does MLS work? explains the mechanics.
Good schemes also change keys over time, so that stealing today’s keys does not expose last month’s messages, and a device that was compromised can recover once it refreshes its keys.
What it does not protect
End-to-end encryption hides content. It does not hide everything else.
- Metadata. NIST’s definition notes that routing information remains visible. Whoever carries the message can usually see who sent it, to whom, when and how large it was. RFC 9420 lists the parts of MLS that are not confidential, including the group identifier and how often its keys change. See what metadata is, and whether encryption hides it.
- The devices themselves. Messages are readable on the endpoints. Malware on a phone, an unlocked device or an unencrypted backup bypasses the encryption entirely.
- Delivery. A server that cannot read messages can still delay or drop them.
- Everything the app does not encrypt. Apps often mix encrypted and unencrypted traffic. In Offline Protocol’s mesh SDK, for example, MLS protects application messages and groups, while service advertisements, requests and responses are signed plaintext that observers can read but not alter undetected.