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

111–120 of 137 posts

Re: Web-based cryptography is always snake oil

#111

Post by echoangle »

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.

Well that’s just wrong, just make it open source and do reproducible builds

Re: Web-based cryptography is always snake oil

#112

Post by charcircuit »

ranger_danger wrote: post #109
charcircuit wrote: post #91

Earlier quoted context omitted.

>Dual_EC_DRBG There is no hard evidence that it was backdoored.

> As part of its efforts to foil Web encryption, the National Security Agency inserted a backdoor into a 2006 security standard adopted by the National Institute of Standards and Technology, the federal agency charged with recommending cybersecurity standards. Credit Patrick Semansky/Associated Press https://archive.nytimes.com/bits.blogs.nytimes.com/2013/09/1... Even if you believe they're lying, or think that it's…

There is no source in the article to support that claim, it links to another article where it merely says that people suspected it of being backdoored, but those people had no proof either. There are objective reasons why it's not a good idea to use compared to better algorithms, but I wish the reasoning was not solely based off of a conspiracy theory or hate for the NSA.

Re: Web-based cryptography is always snake oil

#113

Post by 1vuio0pswjnm7 »

"Thus the client-side code is always distributed by the operator of the web server."

The same goes for client side code distributed by the operators of free "communication services", e.g., Meta (WhatsApp), Signal, etc.

"In other words, web-based "E2E" applications claim to secure against malice on the part of the server operator using encryption implemented in client-side JavaScript, but this is obviously not true, since if the server operator was malicious, they could just push different client-side JavaScript."

Another way to state this is the third party, e.g., the website (server) operator, incorporated as a so-called "tech" company, controls the client software

"It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the "end-to-end encryption" offered by WhatsApp and Signal, amongst other proprietary services, is equally bogus. (Both WhatsApp and Signal ban use of third party clients, and enforce this policy.)"

The vociferous advocates of these "services" in online comments simply refuse to acknowledge this issue

"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."

"The problem is, of course, that "there's nothing we can do" isn't true. The service provider could develop and ship a backdoored version of the client software."

Auto-updates

The number of online commenters that praise auto-updates, is not small

"There are at least two such cases:"

It's possible a client app could have been "updated" with a backdoor, e.g., for some user(s) in some location for some period of time, and no one would be the wiser

It's not possible to know how many cases of compromise by the third party there have been, whether forced or not

Alt least two, perhaps many more

"Eve: But, just to be sure, take this software. It'll encrypt your communications with Bob so that even we can't see them.

Alice: ...Oh, neat. Thanks!

Alice: ...But hold on... you supplied this software.

Eve: Of course.

Alice: So how does it prevent you from seeing my communications?

Eve: It encrypts everything you send before it reaches us. We can't see a thing!

Alice: But this software auto-updates, right?

Eve: Right.

Alice: So you could update it at any time.

Eve: Right.

Alice: So if you ever wanted to spy on my conversation, what's to stop you from just pushing an update to undermine the encryption?

Eve: Ah... well... you know, that's just paranoid. Why would we ever do that?

Alice: In other words, it can't secure my communications against you in case you turn out to be untrustworthy.

Eve: Well... yes...

Alice: So what exactly is it supposed to be securing against?

Eve: OK, you have to trust us, but what about other people? There's all sorts of people trying to eavesdrop on things. So you have to trust us, good old Eve, but nobody else, at least!"

Is "all sorts of people" referring to Eve's competitors and other Eve adversaries such as Eve's users

Eve doe snot want her competitors to be able to collect the data, perform the same surveillance and provide ad services

Eve does not want users to observe Eve's data collection or Eve's client-server protocol lest they might create their own client software

Re: Web-based cryptography is always snake oil

#114

Post by adrian_b »

tptacek wrote: post #71
crote wrote: post #44

Earlier quoted context omitted.

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.

That is not what the comment to which you replied said.

There is a consensus about pushing PQC and about the PQC standard.

The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms.

What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards.

Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.

Re: Web-based cryptography is always snake oil

#115

Post by tptacek »

adrian_b wrote: post #114
tptacek wrote: post #71

Earlier quoted context omitted.

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.

That is not what the comment to which you replied said. There is a consensus about pushing PQC and about the PQC standard. The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken whe…

No, I'm very clear on what the question was asking, and it is not in fact "NSA" driving this process.

This is 100% Daniel Bernstein drama. Bernstein is upset that the NIST contest selected MLKEM (Kyber). He's been running a yearslong crusade to impeach the standard, up to and including opposition to lattice cryptography writ large, despite himself signing on to a lattice entrant (SNTRUP) to the PQC competition.

Over the last several months, the focal point of this crusade has been the IETF TLS Working Group, where Bernstein has been canvassing opposition to an RFC that will establish code points and documentation for pure, non-hybrid MLKEM TLS. Few systems in the near future are likely to use pure MLKEM TLS, but there are conceivable systems that we can foresee needing the option: for instance, embedded systems like smart meters that do ECC today, and could do MLKEM if it was urgently needed because of a CRQC, but couldn't practically do both.

The arguments being made on TLSWG are in spectacularly bad faith. People have varying levels of confidence in pure MLKEM (the closer your job title is to "cryptography engineer", the more likely it is you think hybrids are silly). But outside of the federal government itself, nobody in the entire world is being forced to use pure MLKEM; the entire controversy is about documenting what TLS would look like if you needed pure MLKEM.

The "NSA" stuff is just more innuendo.

Apart from bytes on the wire, MLKEM is not in fact "much more expensive" than 25519. Also, you have the maturity argument wrong; it's not a concern that risks/flaws will be discovered "in the standards".

Re: Web-based cryptography is always snake oil

#116

Post by sneak »

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

Earlier quoted context omitted.

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.

I have all iOS automatic app updates disabled.

Re: Web-based cryptography is always snake oil

#117

Post by autoexec »

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…

Signal doesn't have to backdoor the client (although they could) to be a risk. They upload and permanently store sensitive data in the cloud protected by nothing more than a pin and SGX (https://web.archive.org/web/20250117232443/https://www.vice....) which has already been shown to be vulnerable to side channel attacks (https://web.archive.org/web/20230519120156/https://community...)

Signal seems to be quietly warning people away from the service by refusing to update their privacy policy the very first line of which is a clear lie.

Re: Web-based cryptography is always snake oil

#118

Post by cassonmars »

tptacek wrote: post #115
adrian_b wrote: post #114

Earlier quoted context omitted.

That is not what the comment to which you replied said. There is a consensus about pushing PQC and about the PQC standard. The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken whe…

No, I'm very clear on what the question was asking, and it is not in fact "NSA" driving this process. This is 100% Daniel Bernstein drama. Bernstein is upset that the NIST contest selected MLKEM (Kyber). He's been running a yearslong crusade to impeach the standard, up to and including opposition to lattice cryptography writ large , despite himself signing on to a lattice entrant (SNTRUP) to the PQC competition. Over…

Your argument would be far more charitable if NIST had not already been caught pushing a broken standard at the behest of the NSA before. DJB might be combative and somewhat caustic, but the one thing he's never been, given enough time in the retrospect to show it, is wrong.

Re: Web-based cryptography is always snake oil

#119

Post by d1sxeyes »

> A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.

So once you’ve solved this problem, you’ll need to ensure there’s no software running which can capture the screen and/or keyboard inputs.

Then make sure that every peripheral is running firmware which you know isn’t compromised.

Then make sure the hardware itself is not compromised.

Then make sure the user’s screen is not being recorded. Or visible on any CCTV camera.

There’s a line between utility and perfection. Everything in the real world lives somewhere to the left of “perfection”.

The article is not wrong that there’s a threat model that makes our current ways of doing E2EE less than perfect, but it doesn’t impugn the actual E2EE implementation at all, and is not much different to saying “your data is still not secure because someone could take screenshots!”

Post reply on HN