End-to-end encryption protects a conversation across an adversarial path so that only the communicating people can decrypt the content. Unlike ordinary TLS arrangements, it does not require a central server or middlebox to see messages in cleartext. section 10.1
Figure 10.1 In most systems, a central server (top diagram) relays messages between users. A secure connection is usually established between a user and the central server, which can thus see all user messages. A protocol providing end-to-end encryption (bottom diagram) encrypts communications from one user up to its intended recipient, preventing any server in the middle from observing messages in cleartext.
Compare a server-relayed connection, where the server can read messages, with end-to-end encryption, where encryption continues from sender to intended recipient. section 10.1
Alice sends Bob an encrypted file
Bob gives Alice his public key, Alice encrypts the file with it, and Bob decrypts the result. The design fails if an attacker replaces Bob’s key before Alice can verify it. section 10.2
A usable end-to-end encryption system must address:
- The communication path: TLS may protect user-to-server links while leaving the trusted server able to inspect messages. section 10.1
- The root of trust: users need a known public key or a trusted out-of-band channel. section 10.2
- The application design: modern messaging protocols are generally better suited than email systems built without encryption in mind. section 10.6
Trust remains the difficult part. Public-key cryptography can encrypt messages, but it cannot by itself prove that a received key belongs to the intended person. Systems therefore use approaches such as a web of trust, public key infrastructure, social key discovery, or established out-of-band channels. section 10.2 section 10.6
