Web-based cryptography is always snake oil

Nowadays, there is an epidemic of web applications purporting to offer “end-to-end” encryption. Examples might range from a file upload service, which allows you to upload and share files of arbitrary size and promises “end-to-end encryption”; or a web-based password safe service which claims that it can't see your passwords because they're encrypted; or a web-based cryptocurrency wallet. The cryptographic claims made by these services are invariably nonsense. Indeed they necessarily must be, because the web as a platform does not possess the necessary functionality which would allow otherwise. Fundamentally, all web-based cryptosystems are incoherent because they suffer from an incoherent threat model. Let me start by coining a law, which is both obvious and yet, to my knowledge, novel and overdue:

A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.

It is inherent to the model of the web platform that the code which implements a client-side web application is distributed by the given website. Thus the client-side code is always distributed by the operator of the web server. In other words, web-based “E2E” applications claim to secure against malice on the part of the server operator using encryption implemented in client-side JavaScript, but this is obviously not true, since if the server operator was malicious, they could just push different client-side JavaScript. (Conversely, entities other than the server operator are secured against via use of TLS, so there is no additional benefit to “E2E” if you trust the server operator.) The web platform does not contain any functionality which could be used to separate this relationship (e.g., to distrust server operators for the purposes of what client-side code can execute for an origin), so this problem is intrinsic to any attempt to implement “E2E” encryption in a web application. There are no exceptions. It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the “end-to-end encryption” offered by Whatsapp and Signal, amongst other proprietary services, is equally bogus. (Both Whatsapp and Signal ban use of third party clients, and enforce this policy.)

By any normal definition of the term, a cryptosystem is backdoored if the vendor of a cryptosystem retains the ability to bypass it after its deployment. In this regard all web-based “E2E” cryptography can be regarded as backdoored, as can Whatsapp, Signal, etc.

A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.

Cryptography theatre: Snake oil cryptography as a legal technology This, of course, raises the question: why is this snake oil crypto so popular? Why have companies like Meta spent substantial amounts of money equipping messenger systems like Whatsapp with snake oil crypto? The actions of these companies can't be understood from the perspective of offering actual security, because their actions aren't congruent with this objective and their threat model is incoherent. The real motive for the popularity of “E2E” amongst tech companies actually turns out to be fairly obvious: the purpose of adopting snake oil “E2E” is not to deliver actual security, but to act as a kind of cunning legal maneuver to exempt themselves from the usual legal obligation to honour warrants, subpoenas and other court orders. By nominally adopting “end to end encryption”, these companies can theatrically throw up their hands when the government comes to them with a warrant: “Well, we'd love to help you, but there's nothing we can do!” After all, warrant processing is simply an annoying cost centre and liability for these companies. By simply casting the spell of applying snake-oil cryptography to their product, a company can magically exempt itself from this entire category of legal obligation, reducing both their costs and their potential legal liabilities. The problem is, of course, that “there's nothing we can do” isn't true. The service provider could develop and ship a backdoored version of the client software. The actual gambit the service provider is counting on here is a particular legal theory: “we could change the software so as to be able to process this warrant, but you can't make us do so”. You could perhaps call this cryptography theatre.

The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell which (the user believes) gives them a magic opt out from the obligations conferred by warrants and subpoenas. Thus, cryptography theatre must fundamentally be understood not as a cryptographic technology but as a legal one. There are several problems with this legal “magic spell”. In particular, this legal theory (“you can't make us compromise our system”) seems to be relatively specific to US case law and the typical company offering snake-oil cryptography is based in the US. There are some points of constitutional law which seem to act in favour of this argument, like the fact that the First Amendment is supposed to preclude compelled speech just as much as the prohibition of speech, and there is case law that code is a form of speech. These sorts of protections are unlikely to be effective in other countries. Moreover, the US government clearly does not agree with this interpretation, as it has repeatedly argued that it can in fact force an entity to compromise a cryptosystem it distributes. There are at least two such cases:

The Lavabit incident: When Edward Snowden leaked the Snowden documents, he used a Lavabit email address. Lavabit was an email service boasting web-based (and therefore snake-oil) encryption functionality. The FBI attempted to coerce the owner of Lavabit to compromise the client-side code to allow decryption of Edward Snowden's messages. The owner, rather honourably, chose to shut down the entire service rather than comply (which is to say that they had the ability to comply). I don't know what legal options the owner of Lavabit explored. It is possible they took legal advice and concluded they had an obligation to comply, but also possible they simply decided they didn't have the budget or appetite for complex and extended litigation against the US government. I suspect the latter.

The FBI—Apple case: In which the FBI tried to use US law to coerce Apple to make a version of the iOS firmware which was compromised so as to enable them to decrypt a suspect's iPhone. The FBI eventually withdrew before a decision was made, after gaining access to the iPhone in question another way.

It is fairly clear they don't intend to let this matter settle, however. (It is worth noting that Apple's defence fundamentally was of the argument that we don't want to and you can't make us, not that they did not have the ability to. Since the security controls the FBI was complaining about in this case are ultimately enforced by Apple-signed proprietary firmware, Apple could create firmware defeating these controls if it wanted to, which the FBI was seeking to force it to do. In this regard, iOS also can be regarded as backdoored, as the vendor retains the ability to compromise the system.)

In short, the problem with relying on this sort of thing is that it can be unmade by a new legal ruling at any time, which is a much weaker standard than we are generally seeking to obtain when adopting cryptography. Again, cryptography theatre must fundamentally be understood as a legal technology, not a cryptographic one. The final reason why relying on this legal “magic spell” is not safe is because the assumption that governments are meaningfully bound by law is demonstrably overwhelmingly false. Governments routinely coerce companies into helping with their surveillance initiatives in ways that subsequently turn out to be illegal. In fact this is not even speculative in light of past programs like PRISM, which targeted companies such as Facebook (now Meta); thus it's basically a given that these companies remain compromised and retain a working relationship with governmental intelligence services. Reiterating the above, as a dialogue

Alice: I'd sure like to talk to Bob sometime. If only there were some kind of communications system that allowed me to do that with him on the other side of the world... Eve: Hey there! Alice: Oh, hello. Eve: Our state of the art EveMessenger instant messaging system will let you talk to Bob in no time. Alice: Oh, wonderful! Let me just send him a message... Eve: Whoa, wait! Alice: What? Eve: Aren't you worried I might, you know, eavesdrop on your message to Bob? Alice: Why, would you? Can't I trust you? Eve: Oh, but of course you can. In fact, we're incredibly trustworthy.

You won't believe how trustworthy we are. Eve: But, just to be sure, take this software. It'll encrypt your communications with Bob so that even we can't see them. Alice: ...Oh, neat. Thanks!

Alice: ...But hold on... you supplied this software. Eve: Of course. Alice: So how does it prevent you from seeing my communications? Eve: It encrypts everything you send before it reaches us. We can't see a thing! Alice: But this software auto-updates, right? Eve: Right. Alice: So you could update it at any time. Eve: Right. Alice: So if you ever wanted to spy on my conversation, what's to stop you from just pushing an update to undermine the encryption? Eve: Ah... well... you know, that's just paranoid. Why would we ever do that? Alice: In other words, it can't secure my communications against you in case you turn out to be untrustworthy. Eve: Well... yes... Alice: So what exactly is it supposed to be securing against? Eve: OK, you have to trust us, but what about other people? There's all sorts of people trying to eavesdrop on things. So you have to trust us, good old Eve, but nobody else, at least! Alice: Hold on a minute. Alice: Even without this special software, the channel between my computer and your messaging system is securely encrypted, right? Eve: Yes, that's true... Alice: And the same is true of Bob's channel between his computer and your messaging system, right? Eve: Yes... Alice: So even without this special software, nobody else would be able to eavesdrop on my messages. So if this special software doesn't prevent any third party from eavesdropping on my messages who wasn't already prevented from doing so, and it doesn't prevent you, the service provider from eavesdropping on my messages, who does it prevent from eavesdropping on my messages? Eve: Uh... Eve: ... Eve: ... Eve: ... Eve: OK, look.