This reminds me Telegram, which promises to be secure, but requires giving it my phone number, which is the most insecure thing one can do.
1. Aren't E2EE systems designed to prevent decryption of content already created in the past sitting on the vendor's servers? Yes, the vendor could go rogue, but, assuming they currently have implemented E2EE right, it means any change to the client can only compromise content created in the future from that point onward, no? So why is the article implying Apple could have provided a back-doored iOS to bypass the encryption for existing content?
2. I also don't find the argument that E2EE is only a legal trick fully convincing. There are several other incentives for a vendor to implement it apart from avoiding legal issues: preventing insider abuse, reducing liability, improving customer trust, and resisting mass surveillance
These are real engineering motivations. The threat model is not: "Protect you if <vendor> becomes actively malicious tomorrow." Its more like "Protect messages stored on <Vendor>'s servers from attackers, employees, hackers, routine legal requests, and passive surveillance."
It's on the level of "you can't trust your OS unless you wrote it yourself" -righteous sounding but utterly stupid in practice
This means that, in practice, iMessage is not e2ee.
Before you say "But what about Advanced Data Protection that enables e2ee for iCloud Backup?" - virtually nobody has this on, Apple prohibits you from turning it on in the UK, and even if you enable it - the people you iMessage with don't, so your conversations are in their backups. This means that if either endpoint of the iMessage conversation is in the UK, and both parties have iCloud Backup enabled (the default), then your iMessages are not e2ee as a non-endpoint has an escrowed copy of the plaintext or keys.
Also no OS integrated system that does this for you automatically / conveniently has ever existed that was widely adopted because that application would have the ability to read all of your private communication, and impossible to install on an uncracked phone.
Still it would take literally minutes to vibe code an app that sits in front of a WhatsApp client and automatically handles these things. Maybe the future is just to write it yourself (not the security) so you can trust it and it’s convenient.
The solution obviously is to go out-of-band:
> When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.
[0]: https://securedrop.org/news/introducing-webcat-web-based-cod...
[1]: https://securedrop.org/news/browser-based-cryptography/
This is both true, and also useless: pretty much any E2E system is falling under this definition.
By definition you can't protect yourself from the entity that provides you the software you use, because you have now way to guarantee that they aren't going to backdoor you.
That doesn't mean it's snake oil though, as the entity you want protection against is generally not the software provider but a third party. Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on.
It also means you are safe from data leaks, which are by far the most common threat today.
No system can be secure unconditionally, it's always secure under a particular threat model. And in practice “the attacker is able to deploy arbitrary code on your behalf for an extended period of time without being detected ” is a much narrower attack surface than “the attacker is able to obtain read-only access to your DB or your backups for at least a few minutes”. In the former case, the encryption being broken is also the least of your concern, as you've basically given remote access to all of your user's devices at this point…
Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side and we only get the encrypted data, that is verifiably valid encryption.
I could be malicious and also send a copy of your actual plaintext to the server as well, but that is trivial to check (unless I'm being targeted and I am the only user that gets the malicious code, still, I can check). It's a risky proposition for an organization with vested interest in being seen as pro privacy.
But I get it, different conversation if the government coerces you, and the outcome depends on your bank account and ability to handle pressure.
for this to work in practice it needs to be paired with reproducible builds, open source and either p2p or server choice (use signal.mydomain.net instead of signal.org). but these are all things that already exist and none of them is really hard to set up. the harder problem is distributing community block lists of bad package versions but that can be done with atproto or simple ublock style filter files.
i think the real bottleneck for adoption is that the only browser with built in ipfs support is brave, the one thats full of crypto ads and affiliate link fraud. i dont know if firefox would ever take it up or we need to build a brand new browser. or find a way to do it one layer down with a system service.
Articles like this remind me that non-devs think "end-to-end encrypted" means it's always the case and they can't turn it off at will. This is not the case.
A sophisticated actor might as well also control the application that ends up on my device. It does not have to be the same delivery mechanism as long as I did not write it myself.
So all cryptography is snake oil?
___
I mean I kinda sorta get the point and there would be some merit to discuss there, but the weird framing makes that very hard to do.
Of course it's easier to break web e2ee if you are for example cloudflare compared with someone also having to compromise the Debian repos.
But that's not what snake oil means.
I think what makes the Web special is precisely that there are different browsers beyond Chromium. If the Web was Chrome I would tend to agree but even though popular I do not think it is fair to conflate it to be the Web.
Some might call this a “cryptographic innovation.” I call it “the technical outsourcing of legal disclaimers.” Unfortunately, I don’t seem to have a Harvard Law School legal team on my side.
There are limits to this of course. You can’t buy a TACLANE[1], but you can buy many of the other products[2] USG uses to protect its own classified information.
[1] https://gdmissionsystems.com/encryption/taclane-network-encr...
[2] https://www.nsa.gov/resources/Commercial-Solutions-for-Class...
still this wouldn't guarantee that all the other nodes are not compromised
Also, on iOS, almost everyone has app autoupdates turned on because that's the default.
If web-based encryption is snake oil, then science-based medicine is also snake oil, because you trust your doctor not to secretly give you sugar pills instead of the real thing. In fact, this argument applies even more strongly to medication, because I can't really determine what a pill does, but I can determine what an app or website does and what it sends to the server.
My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.
The article's argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
Sure, the article makes good arguments about the trust that is still implicit in E2EE, but it goes too far in its dismissal of it.
This. The author is dismissing the whole web-based cryptography, or any end-to-end cryptography for that matter, on the basis of a one-dimension analysis.
This is not true. I can build Signal from source from GitHub, and use Signal-the-service with the client (which did not come from Signal, but GitHub/my compiler).
Many cryptosystems are like this. In any case, if you are getting something from the App Store, you can get it once and disable autoupdates, which prevents the service provider (presuming they are the same as the people who published the app) from backdooring you at some point in the future. Alternately, even with updates, unless Apple is colluding with them to serve only you* a specific backdoored app, you can at least be reasonably confident that it's not specifically backdooring only you* in an undetectable fashion.
Absolutely, and the claim is somewhere between nonsense and pedantry bordering on nonsense.
The exact same thing is true for, say, Signal. The provider delivers the client, and they aggressively block non-official clients from participating. So the “ends” in end-to-end are ultimately controlled by Signal. But as long as you trust the Signal company not to insert a backdoor into your client, it’s still true that the company can’t read your texts.
The article argues that Signal is an incoherent cryptosystem, because they ship the E2E-encrypting Signal client (and could, hence, backdoor it) that should protect me, the user, against their own infrastructure snooping on me.
As I understand the definition, we would not have an incoherent cryptosystem if I used a third-party client on Signal's infrastructure. Said Non-Signal client would implement E2E encryption, and use the Signal infrastructure, so the entity running the infrastructure is different from the entity providing the client. But is this any better?
Couldn't “Non-Signal Corp.” be coerced by the government (or decide to build a backdoor for their own gain) just as easily as “Signal”?
So I don't think it matters if the entity distributing the client is the same as the one running the infrastructure. It matters if I trust the client. How to implement this (audits, OSS, version pinning, ...) is still an open question to me.
Sure, but can you find an NSA-designed backdoor in the source code?
> you can get it once and disable autoupdates
Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?
What you describe may be possible for an intelligence agency, but completely out of reach for an individual.
> unless Apple is colluding with them
Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model.
> you can at least be reasonably confident that it's not specifically backdooring only you
That's not really reassuring…
Of course, still orders of magnitude harder than just modifying the js bundle, but not a counter-example.
Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."
What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.
Without which TLS is not gonna work.
The article is arguing that in practice you could just send your "encrypted" communications to the browser vendor, or one of the governments on the certificate root list, or someone else in the distribution chain, and have them be the middle man. The security properties of your communications would be the same. Hence "snake oil".
Things like stapling don't change this much, or reduce to TOFU.
E2E makes it less likely that your information will get hacked and reduces the risk that employees will access your information.
The reality is that these security claims are generally subject to internal audit and would need company wide collusion and the risk of a whistleblower or disgruntled former employee if they were violated provides some level of protection that a large tech company offering of e2e doesn’t mean some level of benefit from the user compared to perfect encryption security.
This effect was seen in the Apple vs FBI incident described in the article. The public perception of Apple as a brave defender of user privacy was greatly increased due to that dispute. For all we know, the FBI was in on the conspiracy. In return they might receive the fruits of such surveillance with the only limitation that they would have to disguise the source with parallel construction[2].
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:
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.
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.
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. You got us. Our “end-to-end” encrypted messaging system makes no sense from a technical perspective.
Alice: I'm amazed you're admitting this, but points for honesty.
Eve: We didn't actually adopt this thing to secure things from a technical perspective. Like you say, it makes no sense. Or a cryptographer would say, the threat model is incoherent. It makes no sense for a cryptosystem to be designed to secure against the same entity who provides the software implementing it. Actually, we had a different motivation for implementing it like this...
Alice: What motivation was that?
Eve: We don't actually want to eavesdrop on you — just assume for the time being that that's true. But there are other entities which might — governments, for example, who come to our door with a warrant.
Eve: Actually, to tell you the truth, it's not even really about not wanting to eavesdrop on you. We don't actually care too much about you — who are you anyway? — but frankly, processing all those warrants was turning into a major cost centre. We came to the conclusion that being able to eavesdrop on our users was more of a liability than an asset.
Eve: But with this bizarro encryption system, it's great. When they come knocking with a warrant, we just say “we can't, it's encrypted” and they go away!
Alice: In other words, you made this “end-to-end encrypted” system not to secure against the possibility of you, the service provider, being malicious, but as a sort of legal loophole to exempt yourself from dealing with warrants.
Eve: Pretty much.
Alice: Somehow I find your blatant opportunism almost charming...
Alice: But what happens if the government just demands you ship a version of the software that compromises this encryption scheme? And puts a gag order on you so you can't tell anyone?
Eve: Don't worry, they can't do that.
Alice: Can't they? Why not?
Eve: Well, we think there's enough technicalities in the law that they'd have great difficulty doing that. Probably.
Alice: Didn't the FBI recently bring a case against Apple arguing that Apple should be forced to make a special firmware update that undermines the security of their own phones so that the FBI could break into one of them?
Eve: Yes, they did...
Alice: The FBI withdrew that case, but they seemed quite sincere in their litigation. All it would take is one piece of case law and the government could come demanding you do the same thing.
Eve: Well... maybe...
Alice: Nor is this the first time the government has rejected this premise. Lavabit was a web-based email service which used the exact same model as you. Emails were encrypted using JavaScript in the web browser, so that Lavabit supposedly couldn't access them. But of course, that JavaScript was served from Lavabit's own website.
Alice: One famous user of Lavabit was Edward Snowden. After he fled the US, the FBI went after Lavabit. After the owner of Lavabit explained how everything was encrypted, the FBI started to demand he modify his website to compromise the encryption. In other words, the US government was totally happy to demand Lavabit ship compromised encryption software. Eventually, the owner of Lavabit chose to shut down the entire service rather than compromise it, which is to his credit, but leaves aside the fact that he could have done it, and that the US government has repeatedly tried to force people to do this kind of thing, both in the Apple and the Lavabit cases.
Eve: But we're a US company, you know! And there's case law that code is speech, and that compelled speech is as equally protected against by the First Amendment as restrictions of speech are. Forcing us to ship you compromised software so we can implement a government warrant would violate our rights of free speech.
Alice: That may well be true, and I wish you luck with your legal arguments. But we're now arguing something completely different, aren't we? We started out discussing a cryptosystem — a technical measure — and now we're talking about law. In other words, you're no longer making any cryptographic claims of security at all.
Alice: It seems to me what's really going on here, is that you're using legal tricks to exempt yourself from processing warrants based on an extremely finely calibrated understanding of US law and ways around it. The involvement of cryptography is just a necessary component unto that end. But that understanding of US law is subject to change and evolve, and could be blown open by a single ruling. If that happened, there would be nothing technical preventing you from eavesdropping on everybody, because we already agreed your system provides no coherent model of cryptographic security. The cryptography in this picture is just a necessary technicality to your legal and public relations battle with the US government over surveillance.
Eve: ...That is a pretty accurate summary of what we really get out of this encryption system, yes.
Alice: End-to-end encrypted, you said?
This is an interesting question. One idea I have sometimes considered is if subresource integrity (SRI) hashes could be applied to web service workers:
Since service workers are persistent, the idea is that if you can pin a service worker script file as having a certain hash, it essentially becomes a root of trust for an origin. Unfortunately, service workers currently don't support SRI; I've proposed this feature here.
What this gains you in theory is the ability to permanently bind your website to a root of trust which could potentially be entirely different, and for example in a different jurisdiction, to that of the web server operator.
However, there are still a lot of issues with this approach:
The core of the issue here is that the web is fundamentally designed around the premise of client-side code being distributed by the communications service it relates to; that these two things are coupled together. This model is at once extremely powerful in terms of ease of deployment and portability, and has enabled incredible things; yet at the same time makes the implementation of meaningful client-side cryptosystems on the web platform impossible. Because this model is so deeply ingrained in the nature of the web, it seems like something that can't be easily fixed. It would require a substantial paradigm shift regarding the web's idea of coupling these two things, because a secure cryptosystem inherently requires that these two things not be coupled.