End-to-end encryption

The defining property is where the keys live: only on the endpoints, never with the operator of the relay. That makes E2EE a threat-model statement rather than an algorithm. It protects content against the server, its administrators, its cloud provider and anyone who compels or breaches them; it does not protect against a compromised endpoint, a malicious client update, or screenshots, and in most deployments it does not hide metadata such as who talks to whom, when, from which IP address and how often.

The dominant design for messaging is the Signal Protocol. Each device publishes an identity key and signed prekeys to the server; a sender runs an asynchronous key agreement (originally X3DH, replaced in 2023 by PQXDH, which adds a post-quantum KEM so that recorded traffic cannot later be decrypted with a quantum computer) and then the Double Ratchet. The ratchet derives a new message key for every message through a symmetric KDF chain and mixes in fresh Diffie-Hellman outputs whenever the direction of conversation changes. This gives forward secrecy (stealing today's keys does not reveal yesterday's messages) and post-compromise security (the conversation heals once new DH values are exchanged). WhatsApp and Google Messages' RCS chats use the Signal Protocol, Apple's iMessage moved to its PQ3 protocol in 2024, and Messaging Layer Security (RFC 9420, July 2023) standardises efficient group key agreement with a ratchet tree so that membership changes cost O(log n) instead of O(n).

The weakest point is key authentication. The server distributes public keys, so a malicious or coerced server could hand out its own key and sit in the middle. The countermeasures are out-of-band verification of safety numbers or QR codes and, increasingly, key transparency logs that make such substitutions publicly detectable. Multi-device support multiplies the problem: every linked device, web client and backup is another endpoint. Cloud backups are a classic gap; WhatsApp added optional end-to-end encrypted backups in 2021, and Apple's Advanced Data Protection extends E2EE to most iCloud categories but was withdrawn for new users in the UK in February 2025 after a government demand.

E2EE differs from TLS, which is hop-by-hop and terminates at the provider, and from encryption at rest, where the provider holds the keys. In e-mail, OpenPGP (RFC 9580) and S/MIME provide E2EE for the message body only, leaving headers and subject in the clear. For organisations the trade-offs are concrete: E2EE conflicts with server-side malware scanning, legal hold, archiving obligations and DLP, and lost keys mean lost data. Proposals for client-side scanning to detect illegal content, debated in the EU for several years, would move inspection onto the endpoint and are widely criticised by cryptographers for undermining exactly the guarantee E2EE is meant to give.