Comment by tptacek
1 day ago
There are basically zero practicing cryptography engineers who would agree with the logic you've used here, but I acknowledge this is also someting Durov believes.
1 day ago
There are basically zero practicing cryptography engineers who would agree with the logic you've used here, but I acknowledge this is also someting Durov believes.
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.
8 replies →