End-to-end encryption has become a marketing checkbox. A careful look at what the term means, the conditions under which the guarantee holds, and the considerable territory it leaves uncovered.
Part 2 of 10 in Trust through mathematics
Few phrases in technology have travelled as far from their technical meaning as “end-to-end encrypted”. It now appears on platforms whose architectures differ so fundamentally that the shared label conveys almost nothing. For an organisation deciding where its sensitive communication should live, the label is the start of the inquiry, not the end of it.
This post sets out, as precisely as a general audience allows, what end-to-end encryption guarantees, the conditions attached to that guarantee, and the substantial ground it does not cover.
The Core Guarantee
End-to-end encryption (E2EE) means content is encrypted on the sender’s device and decrypted only on the recipient’s, with the keys needed for decryption held exclusively at those two endpoints. The infrastructure in between – servers, networks, the operator itself – carries only ciphertext it cannot read.
Used honestly, the term makes a specific and strong claim: the service operator is not a trusted party with respect to content. Not “the operator promises not to look” but “the operator is mathematically unable to look”. This is the distinction between assured and verifiable trust drawn at the start of this series, and E2EE is its most widely deployed expression.
Modern implementations, the Signal protocol most influential among them, add two properties that decide how much a single compromise actually costs. Its X3DH key agreement provides forward secrecy, while the Double Ratchet continuously derives new keys and provides recovery after compromise. Between them, these determine what an adversary gains from one successful compromise, which in practice is the question that matters.
The Conditions, Which Matter As Much As The Guarantee
The guarantee above holds only under conditions that deserve more attention than they get.
Key distribution has to be honest. When you message someone, your device encrypts to what it believes is their key. If the operator can substitute a key it controls – silently adding an extra “recipient” to your conversation – the encryption still works perfectly whilst the confidentiality quietly evaporates. This is not hypothetical: it is precisely the mechanism proposed in various lawful-access designs, sometimes called the ghost protocol. Defences exist – safety numbers, device-verification ceremonies, and key-transparency systems that help clients confirm which keys belong to an account – but whether a platform implements them, and whether anyone uses them, varies enormously.
The implementation has to match the protocol. A sound protocol implemented carelessly offers little, and the published, repeatedly audited implementations have earned a confidence that closed, unaudited ones simply have not. “We use the Signal protocol” is also not the same claim as “we use Signal’s audited implementation of it”.
Backups must not quietly undo it. This is the most common failure in practice. A platform can encrypt messages end-to-end and then upload an accessible copy of the entire history to cloud backup – sometimes by default, sometimes through the other party’s settings. The conversation is then exactly as confidential as the weakest backup configuration of anyone in it. Cloud-synced authenticator apps raise the same structural problem for second factors: the secret is generated locally, then exported to infrastructure someone else controls.
Both endpoints have to stay uncompromised. E2EE moves the attacker’s problem to the endpoint; it does not remove it. Commercial spyware of the Pegasus class exploits the endpoint rather than breaking the encryption, gaining access after decryption has happened on the device. For most organisations the realistic version of this risk is more mundane: a personal phone, out of date, full of over-permissioned apps, holding the firm’s most sensitive conversations.
What E2EE Does Not Cover At All
Even perfectly implemented, end-to-end encryption is silent on several fronts.
It says nothing about metadata – who talks to whom, when, how often, from where, and in what bursts. Content encryption does nothing to conceal any of it, and for many adversaries it is the more valuable signal, which is why it gets a post of its own later in this series.
It says nothing about membership and identity. Encryption guarantees that only conversation participants can read messages; it says nothing about whether the right people are the participants. In organisational settings – joiners, leavers, lost devices, group sprawl – governance of membership is frequently the weaker control. A platform can be cryptographically impeccable and organisationally porous.
It says nothing about availability and retention. E2EE does not promise the service will exist tomorrow, that history is preserved, or that it is deleted when policy says it should be. Those remain assured-trust matters, governed by contract and operations.
And it says nothing about the operator’s commercial behaviour. An operator that cannot read message content can still observe, monetise, and share a great deal about usage. The encryption claim and the privacy claim are related but distinct, and marketing tends to blur them deliberately.
Questions That Separate The Serious From The Decorative
For an organisation weighing platforms, a short list of questions does most of the work:
- Is the protocol published, and has the implementation been independently audited?
- How are keys distributed, and what stops the operator inserting one of its own?
- What happens at backup – is history re-encrypted under user-held keys, or does it land in accessible cloud storage?
- Can the organisation govern membership, devices, and offboarding, or does it inherit whatever each user’s personal configuration happens to be?
- What does the operator retain and observe even when content is unreadable?
Honest answers to these are rarer than the E2EE label. The one to ask first is what happens at backup, because that is where the guarantee is most often quietly undone. We have spent enough time on both sides of this problem – assessing platforms for clients, and building SemaFore for organisations that need the answers to be structurally good rather than contractually promised – to say that the gap between label and architecture is where most of the real risk sits.
End-to-end encryption, done properly, is one of the most powerful tools an organisation can deploy: it removes the operator from the trust equation for content, which is no small thing. But it is a precise instrument with precise boundaries. Treating the label as a synonym for “secure” – rather than as one strong guarantee surrounded by conditions and gaps – is how organisations come to be surprised by incidents their encryption was never meant to prevent.