Live data from Hacker News

Web-based cryptography is always snake oil

devever.net

41–50 of 137 posts

Re: Web-based cryptography is always snake oil

#41
post #25

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

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

Hm not necessarily. You "just" need to get code onto the system that is somehow being loaded into the gpg process or has the ability to load code into a gpg process.

Of course, still orders of magnitude harder than just modifying the js bundle, but not a counter-example.

Snake oil is just a fundamentally wrong label for the issues OP is seeing, even though those issues are of course real and relevant.

Re: Web-based cryptography is always snake oil

#42

Earlier quoted context omitted.

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

The article is nothing but a rant.

Craigslist used to have a Rants & Raves section for exactly these kind of things. I think they still have, but in old times it used to be so happening! Maybe hacker news needs to have one.

Re: Web-based cryptography is always snake oil

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

> 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 respect to the server.

I agree with you though that most current software that are made to auto-update at any time without any oversight do not fall under this umbrella. Web apps definitely don't fall under it.

Re: Web-based cryptography is always snake oil

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

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 probably-more-secure approach of layering the two - while at the same time mandating the use of two layers of those same algorithms for their own use[4]!

[0]: https://en.wikipedia.org/wiki/NOBUS

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

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

[3]: https://blog.cr.yp.to/20251004-weakened.html

[4]: https://defense-solutions.curtisswright.com/capabilities/tec...

Re: Web-based cryptography is always snake oil

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

Re: Web-based cryptography is always snake oil

#47
post #25

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

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

Re: Web-based cryptography is always snake oil

#48
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!"

Re: Web-based cryptography is always snake oil

#49
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

Re: Web-based cryptography is always snake oil

#50
post #10
post #9

Earlier quoted context omitted.

I never believed that the messages were truly E2E encrypted and I know for sure when WhatsApp retroactively censored a message I sent to a friend a while back, I found that super sus.

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.
Post reply on HN