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

31–40 of 137 posts

Re: Web-based cryptography is always snake oil

#31

Post by sneak »

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…

> 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 the service provider (presuming they are the same as the people who published the app) from backdooring you at some point in the future. Alternately, even with updates, unless Apple is colluding with them to serve only you* a specific backdoored app, you can at least be reasonably confident that it's not specifically backdooring only you* in an undetectable fashion.

Re: Web-based cryptography is always snake oil

#32

Post by sneak »

p-e-w wrote: post #24
figassis wrote: post #19

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…

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 to modify the code on your own system.

Re: Web-based cryptography is always snake oil

#33

Post by InsideOutSanta »

jongjong wrote: post #12

As a developer, when some company says that some platform is end-to-end encrypted, you know that it means "the default client provides encryption, by default" but you know very well that they could selectively turn it off for anyone, at any time and it may be impossible to know that they did this this unless the target was tech savvy and actively monitoring their network packets during the brief period that encryptio…

Yeah, this argument is nonsensical as presented.

If web-based encryption is snake oil, then science-based medicine is also snake oil, because you trust your doctor not to secretly give you sugar pills instead of the real thing. In fact, this argument applies even more strongly to medication, because I can't really determine what a pill does, but I can determine what an app or website does and what it sends to the server.

Re: Web-based cryptography is always snake oil

#34

Post by sneak »

tancop wrote: post #29

this is one of the problems content addressed stores like nix and ipfs can prevent. every version of the code is immutable and impossible to delete. if the devs update the "latest pointer" to a backdoored release users can just stay on the old version or move to a fork. and in the happy case (honest developer) you get all the benefits of auto update. for this to work in practice it needs to be paired with reproducibl…

Signal clients have a built in time bomb in each version to "force" you to upgrade after a period of time. It can, of course, be patched out (and I patch it out, along with other fuckery such as disappearing messages/expiring messages/remote delete) but to say that "reproducible builds + content-addressing distribution" solves this problem is basically false in practice.

Also, on iOS, almost everyone has app autoupdates turned on because that's the default.

Re: Web-based cryptography is always snake oil

#35

Post by sneak »

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…

This is precisely why I have autoupdates disabled for my Signal apps. They're on by default, which basically gives Signal-the-org remote code execution on my machine (same as Chrome's built in transparent autoupdate gives Google RCE on your machine).

Re: Web-based cryptography is always snake oil

#36

Post by stymaar »

sneak wrote: post #31
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…

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

What you describe may be possible for an intelligence agency, but completely out of reach for an individual.

> unless Apple is colluding with them

Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model.

> you can at least be reasonably confident that it's not specifically backdooring only you

That's not really reassuring…

Re: Web-based cryptography is always snake oil

#37

Post by adirelle »

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.

Re: Web-based cryptography is always snake oil

#39

Post by sscaryterry »

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.

The article is nothing but a rant.

Re: Web-based cryptography is always snake oil

#40

Post by upofadown »

hypfer wrote: 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 disguised as something else to evade scrutiny.
Post reply on HN