Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web-based cryptography is always snake oil

devever.net

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Web-based cryptography is always snake oil

#51

Post by upofadown »

stymaar wrote: post #16

> 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…

>...pretty much any E2E system is falling under this definition.

The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.

Re: Web-based cryptography is always snake oil

#52

Post by subscribed »

TuringTux wrote: post #14
somezero wrote: post #4

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.

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…

Perhaps Molly[1] could serve as an alternative client for you?

[1] https://molly.im/

Re: Web-based cryptography is always snake oil

#53

Post by upofadown »

adirelle wrote: post #37
stymaar wrote: post #16

> 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…

> the entity you want protection against is generally not the software provider but a third party. 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.

But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.

Re: Web-based cryptography is always snake oil

#54

Post by daft_pink »

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.

Re: Web-based cryptography is always snake oil

#55

Post by bigfatkitten »

crote wrote: post #44
bigfatkitten wrote: post #22

Earlier quoted context omitted.

One thing you can do is have your adversary put their money where their mouth is and use the very same products, sourced independently, that they use to protect their own sensitive information. 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…

The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it. A more modern example is probably the NSA aggressively pushing[3] for replacing classical encryption with post-quantum encryption, rather than taking the more conservative and pro…

> The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it.

The problem with these examples is that they weren't used in national security systems, which are the systems for which NSA has a legislated defensive responsibility.

Clipper was designed for use by the public; it was not intended to ever be used to protect classified (or even sensitive unclassified) information at all.

Likewise with Dual_EC_DRBG. The CSfC component requirements drew from the Common Criteria Protection Profiles, where Dual_EC_DRBG was never an option.

Re: Web-based cryptography is always snake oil

#57

Post by beng-nl »

archerx wrote: post #50
beng-nl wrote: post #10

Earlier quoted context omitted.

Can you be sure WhatsApp retroactively censored a message? Implying someone else but the direct recipient could read and delete/change it? (I believe group chats are different, forgot the details.) I don’t want to be dismissive but.. well i dont believe this is the best explanation given just these observations.

It said the message was removed for violating some rule or something. The message was a link to a website meta does not approve of but it was removed like a day later.

Wow, that is honestly a bit freaky - first I’ve heard of anything like that. I will assume it was a client side action, but still horribly invasive if that’s how it went. I’ll try to find more about this possibility.

Re: Web-based cryptography is always snake oil

#58

Post by subscribed »

stymaar wrote: post #36
sneak wrote: post #31

Earlier quoted context omitted.

> This is both true, and also useless: pretty much any E2E system is falling under this definition. 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 t…

> This is not true. I can build Signal from source from GitHub 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…

>> This is not true. I can build Signal from source from GitHub

> Sure, but can you find an NSA-designed backdoor in the source code?

You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.

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

That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.

You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few".

I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR.

> 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?

I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.

Non sequitur.

Re: Web-based cryptography is always snake oil

#59

Post by stymaar »

xg15 wrote: post #46
stymaar wrote: post #16

> 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…

> 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. You don't need E2E for that, using https/TLS for transport and servers hosted in the US would be enough.

It will be enough until the server is pwnd and the data is leaked to the world.

Data breaches happen literally every day.

Re: Web-based cryptography is always snake oil

#60

Post by stymaar »

upofadown wrote: post #51
stymaar wrote: post #16

> 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…

>...pretty much any E2E system is falling under this definition. The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.

> The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example.

How can you be sure that the entity distributing the software didn't backdoor it?

> the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging

There's literally no substance about that claim in TFA.

Post reply on HN