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

61–70 of 137 posts

Re: Web-based cryptography is always snake oil

#61

Post by stymaar »

upofadown wrote: post #53
adirelle wrote: post #37

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.

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.

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

Re: Web-based cryptography is always snake oil

#62

Post by stymaar »

subscribed wrote: post #58
stymaar wrote: post #36

Earlier quoted context omitted.

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

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

That was never my claim. The claim is that you cannot protect youself from Signal being malicious if Signal is the maker of the software. Compiling the software yourself doesn't help against the kind of adversary in the threat model.

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

Lucky you, you only need to fully audit the codebase every 3 months.

I'm using the Signal apk directly so I'm painfully aware of the frequency of the breakages.

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

I don't think you understand my point. I'm not talking about the CVE being exploited against you. The CVE will just push you to download the compromised update, breaking your “security through lack of update” policy.

Re: Web-based cryptography is always snake oil

#63

Post by conartist6 »

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…

It's not useless, I don't think.

If the software is open source and you only install new versions after their source code has been audited, you should be ok.

Re: Web-based cryptography is always snake oil

#64

Post by xg15 »

stymaar wrote: post #59
xg15 wrote: post #46

Earlier quoted context omitted.

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

But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.

Re: Web-based cryptography is always snake oil

#65

Post by stymaar »

xg15 wrote: post #64
stymaar wrote: post #59

Earlier quoted context omitted.

It will be enough until the server is pwnd and the data is leaked to the world. Data breaches happen literally every day.

But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.

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 access to all of your user's devices at this point…

Data breach occur every day, rootkits being covertly deployed in production apps for a substantial period are much rarer. E2ee only protects against the former, like a safety belt only prevent you from frontal shocks. Nobody would say they are snake oil because of that.

Re: Web-based cryptography is always snake oil

#66

Post by teravor »

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…

a website can serve you a keylogger client and no one will ever know most likely, harder to do with binaries/sources

Re: Web-based cryptography is always snake oil

#67

Post by p-e-w »

sneak wrote: post #32
p-e-w wrote: post #24

Earlier quoted context omitted.

> Isn't this conflating encryption with trust? 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 backdo…

Signal does not aggressively block non-official clients. I constantly use a modified version of Signal Desktop containing a small set of my own patches, and it always works fine. Also, while autoupdate is on by default for the Signal client (and it includes a time bomb expiration to attempt to "force" you to upgrade regularly (removing this is one of my patches)), you are free to turn it off and remove their ability…

This doesn’t work on iOS, where you can’t selectively disable automatic updates for a single app.

Re: Web-based cryptography is always snake oil

#68

Post by eptcyka »

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…

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

But with repro builds and system transparency, hiding backdoors is impractical.

Re: Web-based cryptography is always snake oil

#69

Post by taormina »

prmph wrote: post #17

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

Alright, I'm ready. These are engineering motivations, as you said. So, which one of these isn't a cost center? Because an insurance policy would handle the first two, but probably cheaper. Customers have repeatedly proven they will buy the product lacking the trust. Resisting mass surveillance? They are the mass surveillance. Which is now a legal compliance based cost center.

* preventing insider abuse * reducing liability * improving customer trust * resisting mass surveillance

Re: Web-based cryptography is always snake oil

#70

Post by SoftTalker »

xg15 wrote: post #43
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…

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

Post reply on HN