Comment by dijit
13 hours ago
I know it's trite to bring in logical fallacies, but you're hinging a response on an appeal to authority without tackling the logic head on. Worse so, you're also engaging in a bit of hyperbole.
E2EE provides strong theoretical guarantee's, but not so if the client is under the network providers control. Governments have already pressured companies to alter clients (Australia's "Assistance and Access Act" allows compelling backdoors in software).
If you don't trust the operator, it's irrational to trust the client they supply, they can do anything before E2EE even kicks in.
I'm not saying E2EE is useless technology, it's just useless in cases where the provider and the network are the same thing. You are gaining very little over TLS in those cases. You can configure "self-deleting" messages if you're worried about other clients logging in.
Regardless, most reasonable security researches I know are actually more concerned with supply chain attacks than ensuring E2EE everywhere, which is precisely what I'm arguing.
An adversary in the client/server cryptography model doesn't need a supply chain attack. They already have the cleartext.
That’s fair for a purely malicious provider in client/server mode (they’ve got the plaintext on the server, no fancy footwork needed), but that’s missing the forest: if the provider is adversarial, E2EE doesn’t magically fix it either. They control the client codebase and distribution (app stores, updates), so backdooring it to snag plaintext pre-encryption is trivial—it’s basically a built-in supply chain vuln they own.
Point is, E2EE only “protects” against server-side compromise if you assume the client is golden, which loops back to trusting the provider not to mess with it. If they’re bad actors, they can (and govts do compel them to) inject client-side leaks (again, see Australia’s TOLA Act forcing software mods), or historical cases like Lavabit’s key handover pressure.
In trusted-provider scenarios (which is most users’ reality), client/server + TLS + encrypted storage suffices against external threats, with less complexity than E2EE’s multi-device key mgmt headaches.
If distrust is total, bail! Because neither model’s your friend. Supply chain worries aren’t a distraction; they’re the real vector, as SolarWinds and Jia Tanning of xz remind us. E2EE’s great tech, but you are pretending that it is a cure-all, which ignores practical realities.
First, the setting for secure messaging cryptography assumes a compromised provider, so this is all entirely besides the point. But second, no, it's not exclusively a problem for a "purely malicious provider". It's also a problem for any provider that is compromised; a serverside compromise is completely fatal to the privacy of every user of a client-server-encrypted system.
There isn't an amount of hand-waving that's going to get you to a place where client-server-only encryption is sufficient for secure messaging.
I am also more concerned about supply chain attacks than I am about attacks on E2EE, generally. But that stops being true in the specific case of secure messaging.
7 replies →