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

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…

  Code Verify works in partnership with Cloudflare, a web infrastructure and security company, to provide independent, third-party, transparent verification of the code you're being served on WhatsApp Web. We hope this gives at-risk users peace of mind. 

The author is basically saying if you participate in any part of the encryption process, you're deceiving users in saying things are e2e encrypted.

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.

As a developer, when some company says that some platform is end-to-end encrypted, you know that it means "the default client provides encryption, by default" but you know very well that they could selectively turn it off for anyone, at any time and it may be impossible to know that they did this this unless the target was tech savvy and actively monitoring their network packets during the brief period that encryption was turned off... Especially on the web, they could just serve a different JavaScript library with a backdoor to a specific IP address only and the target would have no idea.

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.

The entire argument is based on the definition of an “Incoherent cryptosystem”, which is too restrictive to be useful for cases that you want eg. Tor is also developed and distributed by Tor people and it is supposed to protect you against everyone, including the Tor people.

Something I don't understand about this argument, which has been made before, is you can tie JavaScript to a specific hash with SRI. So you release the cryptographic code in public where it can be audited and then what runs in the browser verifies that was what loaded.

The host could inject malicious JavaScript from the host or change libraries but I feel like this is an avoidable problem because it can be audited much more easily than expecting users to audit JavaScript every time. People could even build known, trusted, web frontends. So I think there are mitigations if not ways to assure the browser is running trusted code.

this is one of the problems content addressed stores like nix and ipfs can prevent. every version of the code is immutable and impossible to delete. if the devs update the "latest pointer" to a backdoored release users can just stay on the old version or move to a fork. and in the happy case (honest developer) you get all the benefits of auto update.

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.

I don’t agree with this. While, it may be true that E2E carries risks of government surveillance.

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.

I feel the legal part is on point. It's also increasingly used by governments to have their cake and eat it too: "We'll completely lock down your devices and run all kinds of analysis on your data, but don't worry, it's all done on-device and all communication is encrypted, so our promise to protect your privacy is kept!"

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

So once you’ve solved this problem, you’ll need to ensure there’s no software running which can capture the screen and/or keyboard inputs.

Then make sure that every peripheral is running firmware which you know isn’t compromised.

Then make sure the hardware itself is not compromised.

Then make sure the user’s screen is not being recorded. Or visible on any CCTV camera.

There’s a line between utility and perfection. Everything in the real world lives somewhere to the left of “perfection”.

The article is not wrong that there’s a threat model that makes our current ways of doing E2EE less than perfect, but it doesn’t impugn the actual E2EE implementation at all, and is not much different to saying “your data is still not secure because someone could take screenshots!”

Many comments suggest that the definition and criteria proposed are infeasible and useless. They are not wrong. But still it points out something the layperson misses (or even many tech-savvy people): An E2EE service from A does not provably protect your data against A.

> The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell

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.

Sounds logical to be honest.

The E2E encryption is not protecting you, it's protecting the company providing the software.

The only thing that is legit is the local use of PGP. But it's a shame we don't really progress much.

Before reading this article, I used to believe that IT companies deeply respected users’ human rights, spending millions of dollars to build end‑to‑end encryption. But thanks to this very article, I learned that they were actually saving tens of millions in administrative litigation costs – costs they would otherwise have had to pay every month to respond to wiretap warrants.

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.

That is basically true for every such system. Trust Signal? They could ship a backdoor in the next release. Same with Threema, WhatsApp (if you want to trust it today) and other services. You can expand that to the operating system as well. And who able to verify hardware security, anyway?

Anything you see rendered onto a screen is no longer secure though, or is it a hyperbole to phrase it this way?

The discussion on the proposed solution is interesting

https://github.com/w3c/ServiceWorker/issues/1680

Contrary to the title this isn’t about the web but rather makes an argument against trusting suppliers to hide your messages from the same suppliers.

Reminder: iMessage claims to be e2ee, but the on-by-default iCloud Backup on iOS backs up material that is sufficient to defeat this (either the endpoint keys, in the case of "Messages in iCloud" disabled, or the messages themselves, in the case of "Messages in iCloud" enabled).

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.

PGP remains the only pretty good privacy

(Said tongue-in-cheek, I don’t know if there’s other comparable systems out there)

Two problems I see with the authors argument. Maybe someone more knowledgeable can chip in to correct me if I'm wrong:

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."

If, say, Signal was completely controlled by the CIA[1] and was thus evil, then having incoherent cryptography as described in the article would be a feature, not a bug. Being able to reject law enforcement requests would produce a false sense of security for the people the CIA was interested in surveilling. Responding effectively to law enforcement requests would reduce the value to the CIA of the ability to secretly backdoor Signal.

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].

[1] https://en.wikipedia.org/wiki/Crypto_AG

[2] https://en.wikipedia.org/wiki/Parallel_construction

> the code which implements a client-side web application is distributed by the given website

Incorrect, and trivially falsifiable. Examples:

- Self hosting, where you control both client and server.

- Loading a web app from file:///

- Loading a web app from localhost.

The author's "no exceptions" is simply wrong.

The author also seems to assume the same server is required to both serve the code and store/transmit encrypted messages which obviously isn't the case. In addition the statements about service workers are ignorant.

The rest of the analysis is largely correct and the threat outlined (where somebody can replace your client) is a serious one that many underestimate. In particular the proprietary native mobile app model is vulnerable to this, as mentioned.

I’d rather make up my own mind, read the docs/code. All I read was unsubstantiated claims, with zero real world evidence.

Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?

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.

While there is _some_ truth to what they are saying, it is an unnecessarily hostile and nihilistic take, intentionally eschewing nuance.

Often hot takes like this can serve a good purpose. I'm not sure that this does.

I think the article raises interesting questions about trust, but I am also doubtful if the definition of the “incoherent cryptosystem” is useful:

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.

technically you could audit your local copy of tor source code, build it, and then never upgrade it.

still this wouldn't guarantee that all the other nodes are not compromised

> Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?

Yes, but it's a whole lot of extra steps spread across multiple independent parties, each of them adds large delays to the actions and increasing the chance that it is discovered long before it ends up on the users machine.

When you hack GPG it will take years before it trickles down into every Linux distribution, especially LTS releases. And ideally, you want an encryption protocol, not one app, thus you have some people running GPG, some running Sequoia PGP and some running OpenPGP.js. If somebody fiddles with the encryption, different clients won't be able to decode the messages anymore and it will be clear pretty quickly that something is wrong.

Meanwhile on the Web or smartphones, you remove or backdoor the encryption, everybody gets auto updated to the latest version and nobody will know that something went wrong.

How about GPG distributed with a Linux distribution like Debian as a counterexample? It would be fairly difficult to backdoor GPG in that case without getting caught. Everything happens in the open both at the GPG level and the Linux distribution level. The binaries are signed by the distribution and are distributed by a bunch of mirrors. An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.

That is not what the comment to which you replied said.

There is a consensus about pushing PQC and about the PQC standard.

The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms.

What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards.

Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.