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

101–110 of 137 posts

Re: Web-based cryptography is always snake oil

#101

Post by unbrice »

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…

The argument is that E2E encryption implemented by Non-signal may protect you against Signal but won't protect you against Non-signal

Re: Web-based cryptography is always snake oil

#102

Post by kasey_junk »

delusional wrote: post #81
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. Framing this in terms of governmental espionage is nonsensical. Using e2e from a US-based entity makes you completely sure that the US government is spying on you, because they assert direct control over the soft…

Your access records are only as good as your ability to prevent someone from making unauthorized access.

Re: Web-based cryptography is always snake oil

#103

Post by zzril »

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…

I guess you could make a point for using messengers based on open protocols (like Matrix) that have plenty of different client implementations. It doesn't protect you from targeted attacks (it might if you can somehow hide from the outside world which client you're using, or if you write and maintain the client yourself) - but it makes it less likely to be affected if your favourite agency managed to backdoor some random client implementation.

Re: Web-based cryptography is always snake oil

#104

Post by stymaar »

tarpitt wrote: post #98
stymaar wrote: post #65

Earlier quoted context omitted.

See what I wrote above: > 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 acce…

I would say that they are snake oil because of that. Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.

> Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.

That logic makes no sense. A rootkit is much more valuable than a data breach (because it gives you access to a compromised device), the reason why you don't see more of them is because it's much harder to pull off, not because people don't use e2ee…

(For instance, if you can replace an e-commerce website's code with your own, you get access to the user's payment information, which you can't usually get from their DB since it's generally handled by the payment processor, or to the user's plaintext password…)

Re: Web-based cryptography is always snake oil

#105

Post by stymaar »

tarpitt wrote: post #99
stymaar wrote: post #61

Earlier quoted context omitted.

> means that you are claiming protection from you and your system. Not necessarily. I push for e2ee everywhere I can for a completely different reason: when (not “if”, “when“) we get breached, we cannot leak sensitive data we don't have.

The problem is that your system can be changed at any time such that you can have the information.

Only if you manage to deploy malicious code and have it stay there undetected. But in practice this is much harder than having access to a DB or a backup for a few minutes (that's all it takes to leak data).

(Just as an example, at my current employer, out of 8 people in the company, there are 8 people who have credentials that permit at least some db access in one way or the other (anyone that has at least one of this job: customer support, account managers, data scientists, devs). There are only 3 people who can push changes to production, and you need 2 out of 3 to do so, and all of three get paged when a release happen. Of course it's not infallible, but the probability of the app being corrupted is orders of magnitude lower than the DB being breached, by the mere scale of the number of people who have access to these things. And again, you only need transient access to the data to leak it, when you need persistent access to do damage by corrupting the code. Most companies I worked for had an even worse ratio between people having access to some sensitive data and people having the ability to push corrupted code in production).

Re: Web-based cryptography is always snake oil

#106

Post by zaik »

hoppp wrote: post #92

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.

Gajim recently got a modern PGP implementation: https://gajim.org/posts/2026-06-18-gajim-2.4.7-released/

Re: Web-based cryptography is always snake oil

#107

Post by zzril »

nailer wrote: post #90

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.

in fact, this could be generalized more and doesn't neccessarily have to be about hiding messages. We've all heard the discussions about using VPNs "for privacy" (i. e. for hiding your IP metadata), when it's really just shifting trust away from your ISP and towards the VPN supplier.

It always comes down to who the alternative party to trust would be. In the fictional dialogue, the alternative appears to be to not send the message. Which may or may not be the better option than to give Eve eavesdropping capabilities.

Re: Web-based cryptography is always snake oil

#108

Post by rstuart4133 »

SoftTalker wrote: post #70
xg15 wrote: post #43

Earlier quoted context omitted.

> 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's not completely true. If I can control when (and if!) the software updates and if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor, I can treat it like a third party with…

> if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor This would be extremely difficult, I would say impossible from a practical standpoint.

> This would be extremely difficult, I would say impossible from a practical standpoint.

It's not only practical and possible, it's so common it even has a name in software engineering circles: change control. It boils down to this: you delay installing the software until it's been reviewed, tested and deployed by others. Or as Linus would put it, until the many eyeballs have had their say.

As for "the person in control of the platform": the solution is to remove some of that control. You make new versions of the software available for anonymous download, so the provider has no idea who is upgrading. All open source distributions provide their software in that way. No proprietary platforms I'm aware of do, because they want a "billing relationship" with the customer. Once downloads are anonymous, the owner of the software can't target individuals with a tailored Trojan Horse binary. Everyone gets the same binary, and so there are lots of eyeballs looking at it.

The final piece of the puzzle is reproducible builds, which ensures the many eyeballs can see the code use to build the binary.

All this has been around for a while now, so it's largely a solved problem in open source distributions. The problem with web-based cryptography is it isn't managed like an open source distribution. Downloads aren't anonymous, the source isn't available or signed, and it changes so fast change control isn't possible. So yeah, as things stand it's snake oil. But it doesn't have to be - it's just the way things are now.

Re: Web-based cryptography is always snake oil

#109

Post by ranger_danger »

charcircuit wrote: post #91
crote wrote: post #44

Earlier quoted context omitted.

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…

>Dual_EC_DRBG There is no hard evidence that it was backdoored.

> As part of its efforts to foil Web encryption, the National Security Agency inserted a backdoor into a 2006 security standard adopted by the National Institute of Standards and Technology, the federal agency charged with recommending cybersecurity standards. Credit Patrick Semansky/Associated Press

https://archive.nytimes.com/bits.blogs.nytimes.com/2013/09/1...

Even if you believe they're lying, or think that it's impossible to know because it may be a kleptographic backdoor... the latter at least is understood to be a unique property that most other algorithms do not share, so I think for that reason alone it's enough to assume it is backdoored, insofar as that we should tell people to stay away from it regardless.

Re: Web-based cryptography is always snake oil

#110

Post by ranger_danger »

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.

Anyone using reverse proxies, CDNs or anti-DDoS services already voluntarily give full MITM privileges of their unencrypted data to companies like CloudFlare, Amazon, Akamai, Fastly, etc., which is most of the top sites on the internet and a large percentage of the overall internet traffic.
Post reply on HN