Web-based cryptography is always snake oil
Web-based cryptography is always snake oil<br>Nowadays, there is an epidemic of web applications purporting to offer<br>“end-to-end” encryption. Examples might range from a file upload service,<br>which allows you to upload and share files of arbitrary size and promises<br>“end-to-end encryption”; or a web-based password safe service which claims that<br>it can't see your passwords because they're encrypted; or a web-based<br>cryptocurrency wallet.
The cryptographic claims made by these services are invariably nonsense. Indeed<br>they necessarily must be, because the web as a platform does not possess the<br>necessary functionality which would allow otherwise.
Fundamentally, all web-based cryptosystems are incoherent because they suffer<br>from an incoherent threat model.
Let me start by coining a law, which is both obvious and yet, to my knowledge,<br>novel and overdue:
A cryptosystem is incoherent if its implementation is distributed<br>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<br>a client-side web application is distributed by the given website. Thus the<br>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<br>the part of the server operator using encryption implemented in client-side<br>JavaScript, but this is obviously not true, since if the server operator was<br>malicious, they could just push different client-side JavaScript. (Conversely,<br>entities other than the server operator are secured against via use of TLS, so<br>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<br>separate this relationship (e.g., to distrust server operators for the purposes<br>of what client-side code can execute for an origin), so this problem is<br>intrinsic to any attempt to implement “E2E” encryption in a web application.<br>There are no exceptions.
It is worth noting that this law also applies to non-web applications where the<br>service provider supposedly being secured against is also the client software<br>distributor; thus, the “end-to-end encryption” offered by Whatsapp and Signal,<br>amongst other proprietary services, is equally bogus. (Both Whatsapp and Signal<br>ban use of third party clients, and enforce this policy.)
By any normal definition of the term, a cryptosystem is backdoored if the<br>vendor of a cryptosystem retains the ability to bypass it after its deployment.<br>In this regard all web-based “E2E” cryptography can be regarded as backdoored,<br>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?<br>Why have companies like Meta spent substantial amounts of money equipping<br>messenger systems like Whatsapp with snake oil crypto? The actions of these<br>companies can't be understood from the perspective of offering actual security,<br>because their actions aren't congruent with this objective and their threat<br>model is incoherent.
The real motive for the popularity of “E2E” amongst tech companies actually<br>turns out to be fairly obvious: the purpose of adopting snake oil “E2E” is not<br>to deliver actual security, but to act as a kind of cunning legal maneuver<br>to exempt themselves from the usual legal obligation to honour warrants,<br>subpoenas and other court orders. By nominally adopting “end to end encryption”,<br>these companies can theatrically throw up their hands when the government comes<br>to them with a warrant: “Well, we'd love to help you, but there's nothing we<br>can do!”
After all, warrant processing is simply an annoying cost centre and liability<br>for these companies. By simply casting the spell of applying snake-oil<br>cryptography to their product, a company can magically exempt itself from this<br>entire category of legal obligation, reducing both their costs and their<br>potential legal liabilities.
The problem is, of course, that “there's nothing we can do” isn't true. The<br>service provider could develop and ship a backdoored version of the client<br>software. The actual gambit the service provider is counting on here is a<br>particular legal theory: “we could change the software so as to be able to<br>process this warrant, but you can't make us do so”.
You could perhaps call this cryptography theatre. The purpose of cryptography<br>theatre is not to deliver actual security from a cryptographic perspective but<br>act as a kind of magic spell which (the user believes) gives them a magic opt<br>out from the obligations conferred by warrants and subpoenas. Thus,<br>cryptography theatre must fundamentally be understood not as a cryptographic<br>technology but as a legal one.
There are several problems with this legal “magic spell”. In...