What end-to-end encryption protects, and what it doesn’t

End-to-end encryption (E2EE) is one of the most reassuring phrases in software, and one of the most misunderstood. EFF’s Surveillance Self-Defense guide defines it precisely: it “ensures that information is turned into a secret message by its original sender… and decoded only by its final recipient.” That is a strong guarantee for message content. It is not a guarantee for everything else about the conversation.

What E2EE actually protects: content

When a messaging app implements end-to-end encryption correctly, the company running the service cannot read the messages passing through its own servers — only the sender’s device and the recipient’s device hold the keys needed to decrypt. Signal’s published technical documentation describes the underlying mechanisms, including the Double Ratchet algorithm, which is designed so that “earlier keys cannot be calculated from later ones”: even if one key is ever exposed, past messages stay protected, a property called forward secrecy. This is the part of the promise that holds up well when implemented properly, and it is a meaningful difference from a plain text message or an unencrypted email, both of which any server in the path can read.

What it does not protect: metadata

EFF’s guide is direct about the gap: encryption “hides the content of your messages, but not who is talking to whom, or when, or how often.” Metadata — who contacted whom, at what time, for how long, from what location — can be as revealing as the message itself. Knowing that a source called a journalist the night before a story broke can identify that source even without a single word of the conversation being read. Some services work specifically to reduce this exposure: Signal’s “sealed sender” feature is built so its own servers do not need to know who sent a given message, only who it is delivered to, though Signal’s own writeup on the feature notes that resistance to more advanced traffic analysis — using timing and IP addresses — remains an area of ongoing work, not a solved problem.

What it does not protect: the endpoints

Encryption protects data in transit between two devices. It cannot protect data on a device that is itself compromised. EFF states this plainly: “if your endpoints… are compromised, your encrypted communications can be compromised.” A harmful app with screen-reading access, a device unlocked by someone else, or a message the recipient chooses to screenshot all sit outside what encryption can address — the message was faithfully decrypted exactly as designed, for exactly the person who was supposed to read it, who then did something with it beyond the sender’s control.

What it does not protect: backups

A conversation encrypted in transit does not stay encrypted the same way once it is saved. EFF notes that if you “automatically store backups of encrypted conversations to the cloud,” those backups may not carry the same end-to-end protection the live conversation had — depending on the service and its backup settings, a cloud provider (or anyone who compromises that provider, or is legally compelled to hand over its contents) could potentially read a backup that the original message was protected against. Checking whether an app’s backups are end-to-end encrypted by default, or only optionally, is worth doing once rather than assuming the strongest setting is automatic.

Why this distinction matters in practice

For an at-risk source or client, “we use an encrypted app” is not a complete answer to “are we safe”, because the threats that matter most — being identified through call patterns, having a phone seized and unlocked, or a backup being handed over under legal process — sit largely outside what encryption addresses. The next lesson picks up the piece that keeps all of this working in the first place: the keys and passwords that encryption depends on, and what happens when they are lost or exposed.