End-to-end security
What this criterion guarantees: You know who you are talking to, and you know that nobody else can listen in, not even the operator. In other words, you are having a genuinely private conversation.
Without it: One of the two guarantees is missing, and the other loses most of its value. Perfect encryption to the wrong person protects nothing.
At a glance
• Olvid — ✅ Good
• Signal — ❌ Poor
• WhatsApp — ❌ Poor
• Telegram — ❌ Poor
• Matrix-based — ❌ Poor
• SimpleX — ❌ Poor
• Threema — ❌ Poor
Back to basics: the goal of a secure communication solution is to guarantee two things to its users:
- they know who they are talking to;
- they know that nobody else can listen in.
This property is what we call end-to-end security.
In light of the previous explanations about encryption and authentication, the conclusion is simple: end-to-end security requires both end-to-end authentication and end-to-end encryption.
How do I know whether my messaging app is end-to-end secure?
It is easy to know whether an application implements end-to-end encryption: those that do say so in black and white and, except in the case of Telegram, they can generally be believed on that specific point. On the other hand, it is often hard to confirm that authentication is truly end-to-end (that is, that it relies on no third party). Conversely, it is easy to detect that it is not: if you can add a contact without any interaction with them, then the authentication is not end-to-end.
This is the case with WhatsApp, for example: to add a contact, all you need to do is enter their phone number. No interaction with the contact is required: the application fetches their public key from Meta’s centralized directory and automatically trusts it. This is exactly the directory scenario seen earlier, where the operator can substitute its own key, thereby compromising the encryption of the communications you intend for your contact.
This problem is the reason why some solutions, such as WhatsApp and Signal, let you check that the “automatic” key exchange went as it should. Much like the solution PGP provides, you have to exchange a safety number (60 digits) or scan each other’s QR code face to face. This step removes the security dependency on the server, by placing authentication in the hands of the users themselves. Just as with PGP, this verification step is optional and particularly burdensome. The users who go through it are exceedingly rare. Moreover, this verification can often be bypassed by an adversary who controls the solution’s servers, typically by orchestrating a silent key change or by exploiting how easily the corresponding alerts go unnoticed. This is discussed in the No identity substitution criterion.
Applying this criterion
This criterion is a composite one. Earning a ✅Good requires both a ✅Good for end-to-end encryption and a ✅Good for end-to-end authentication.