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

71–80 of 137 posts

Re: Web-based cryptography is always snake oil

#71

Post by tptacek »

crote wrote: post #44
bigfatkitten wrote: post #22

Earlier quoted context omitted.

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

The NSA isn't aggressively pushing for PQC; the industry is. Note that the PQC standard we have was the product of a competition won by European academic cryptographers.

Re: Web-based cryptography is always snake oil

#72

Post by tptacek »

stymaar wrote: post #36
sneak wrote: post #31

Earlier quoted context omitted.

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

Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".

Re: Web-based cryptography is always snake oil

#73

Post by tptacek »

xg15 wrote: post #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!"

Kind of a weird concern to be reading on HN, where the sentiment is overwhelmingly that these kinds of systems should be exempt from warrants and discovery.

Re: Web-based cryptography is always snake oil

#74

Post by tptacek »

upofadown wrote: post #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 secretl…

The word "if" is doing a whole lot of work in that first paragraph. Holding the entire world on its shoulders, so to speak.

Re: Web-based cryptography is always snake oil

#75

Post by sandeepkd »

eptcyka wrote: post #68
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.

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 so business is least motivated in investing it or say continuously investing in it. The ones that do are doing partial lip service for most part.

Re: Web-based cryptography is always snake oil

#76

Post by onetimeusename »

Something I don't understand about this argument, which has been made before, is you can tie JavaScript to a specific hash with SRI. So you release the cryptographic code in public where it can be audited and then what runs in the browser verifies that was what loaded.

The host could inject malicious JavaScript from the host or change libraries but I feel like this is an avoidable problem because it can be audited much more easily than expecting users to audit JavaScript every time. People could even build known, trusted, web frontends. So I think there are mitigations if not ways to assure the browser is running trusted code.

Re: Web-based cryptography is always snake oil

#77

Post by stymaar »

tptacek wrote: post #72
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…

Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".

It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.

Re: Web-based cryptography is always snake oil

#78

Post by hamburglar »

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…

If you get an open source app from the App Store, is there any assurance it actually reflects the code in the repo? I’d think the signing step happening in isolation opens the door to tomfoolery.

Re: Web-based cryptography is always snake oil

#79

Post by tptacek »

stymaar wrote: post #77
tptacek wrote: post #72

Earlier quoted context omitted.

Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".

It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.

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

Re: Web-based cryptography is always snake oil

#80

Post by stymaar »

tptacek wrote: post #79
stymaar wrote: post #77

Earlier quoted context omitted.

It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.

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.

Post reply on HN