Comment by tptacek
1 day ago
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.
The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters.
If the provider is compromised (maliciously or via hack/subpoena), they can alter the client to capture data before E2EE engages, rendering it moot.
E2EE protects past messages from server-side access, sure, but it doesn’t prevent future compromises via client backdoors, which are a real vector under laws like Australia’s TOLA or US CLOUD Act, again: providers have been compelled to modify software (e.g., Lavabit’s resistance led to shutdown, but others comply quietly).
You’re right that client-server alone fails catastrophically on server compromise, but E2EE isn’t a panacea if the same actor controls the client supply chain.
Trust is binary: If you don’t trust the provider, don’t use their client. reproducible builds help a tiny fraction, but for most, it’s unverifiable.
In partial-trust scenarios (e.g., worrying about hacks but not full malice), client-server with distributed keys and TLS can suffice without E2EE’s complexities.
I’m hand-waving a bit here; but I’m talking about peoples actual realities, not some hypothetical.
How does E2EE hold up if a subpoena forces a silent client update? You won’t know, and history shows that’s the path of least resistance for adversaries.
Client supply chain is moot in the client-server setting. The attackers just target the server and get everything. You only get to raise the salience of the client supply chain when E2EE is already in place. Again: this is an analysis specific to secure messaging.
Slack isn't E2EE secure. The Slack client supply chain is not how I worry about my Slack message history being intercepted.
Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway).
A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny.
It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus.
If you don’t trust the provider, don’t trust their code. Simple as.
4 replies →