Live data from Hacker News

Web-based cryptography is always snake oil

devever.net

81–90 of 137 posts

Re: Web-based cryptography is always snake oil

#81
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 software you are running. There is no venue to seek justice against an unlawful contract if the government is in on it.

You should instead take a step back into reality and consider data misuse by normal non-government actors. Facebook claiming e2e encryption is a contractual matter, that you can litigate. That's where the actual protection is. That's also why real business demands not "unbreakable encryption" but reliable marker for access and tampering. It is much more useful to have a record of who accessed the data, than a claim that it's impossible.

Re: Web-based cryptography is always snake oil

#82
post #80
post #79

Earlier quoted context omitted.

It's not the identity of the agency that makes the argument so slippery!

Do you seriously think that the average Joe is able to find a backdoor, planted by anyone, in a piece of software they aren't familiar with? Because that what quite literally the claim I was arguing with in the first place.

I don't really agree with much of anything you've said in this thread, but the only thing I'm pointing out here is that your argument has shifted and is chugging heartily towards non-falsifiability.

Re: Web-based cryptography is always snake oil

#83
post #24

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

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

Molly has been running just fine as a project for quite a few years at this point. Signal doesn't block them. I think it's fair to say they are fairly strongly opposed to them (for somewhat defensible reasons), but no, they've been fairly nice in allowing other clients.

Re: Web-based cryptography is always snake oil

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

I think the whole US vs. non-US thing is total crap and there's nothing you can reasonably do with it in any direction, but I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.

Re: Web-based cryptography is always snake oil

#85
post #68

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. But with repro builds and system transparency, hiding backdoors is impractical.

Not really, time and time again people have abused their position/influence to build backdoors almost into everything for good or bad reasons. The whole idea of third party audits was to ensure that there are checks and balances. Then again the auditors are lowest paid to get stuff done and they take word of the company for most part. On other hand its quite natural, security is not really getting you direct revenue…

Really? "Time and time again", "almost everything"? Make a list!

Re: Web-based cryptography is always snake oil

#86
post #82
post #80

Earlier quoted context omitted.

Do you seriously think that the average Joe is able to find a backdoor, planted by anyone, in a piece of software they aren't familiar with? Because that what quite literally the claim I was arguing with in the first place.

I don't really agree with much of anything you've said in this thread, but the only thing I'm pointing out here is that your argument has shifted and is chugging heartily towards non-falsifiability.

No the argument hasn't shifted. The core point is that any time you use a piece of software, you have to have some level of trust towards the entity that gave you the said piece of software.

The way I responded to one particular example “what if I download Signal and compile it myself” is just that a particular example, not a shift in argument.

If you think there's no trust assumption in the distribution of software, feel free to provide actual arguments to refute that argument of mine, because so far your comments have been disappointingly lacking in substance.

Re: Web-based cryptography is always snake oil

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

There are levels to this (hermetic/reproducible builds & attestations, as one example). In fact, TFA is harsh for the only case it wants to make an example out of, WhatsApp Web:

  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. 
https://blog.cloudflare.com/cloudflare-verifies-code-whatsap... & https://engineering.fb.com/2022/03/10/security/code-verify/

Re: Web-based cryptography is always snake oil

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

> An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.

The xz utils hack got slurped up into sid before it was discovered by a researcher's performance regression in ssh. IIRC the hacked test file didn't even need to be added to the upstream source tree because Debian was blithely downloading release tarballs from Github. No evil Debian maintainer needed.

It's funny that when speculating about Debian's security you forget an actual state-level attack that got code into sid, but when speculating about Signal's insecurity in another thread you're quite happy to imagine potential state-level attacks.

Post reply on HN