Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Criticism of JavaScript Cryptography

bren2010.github.io

Post reply on HN
Print view View original

41–50 of 84 posts

Re: A Criticism of JavaScript Cryptography

#41

Post by Sanddancer »

nadaviv wrote: post #26

In a project I'm working on [1], I'm planning to provide a browser extension that verifies the source code is digitally signed and that it matches the source code published on GitHub. I believe this creates a pretty good security model for a web-based app, even more so than most desktop programs. Some more information from the security page [2]: The browser extension provides improved security by verifying the integr…

So what happens when github goes down? I'd argue a better source for this sort of thing would be to put the hash in dns, either directly in a txt record, or using hacks involving A or AAAA records. Your nameserver almost certainly has more security than your github repo.

Re: A Criticism of JavaScript Cryptography

#42

Post by rmrfrmrf »

jarrett wrote: post #21
bren2013 wrote: post #16

Earlier quoted context omitted.

This is also precisely the problem I was trying to avoid by introducing formality. Is it like saying that a tank made of paper sheets is insecure, or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)? It is never okay to omit important information like the threat model in cryptography. That information is essential to the system's analysis.

> Is it like saying that a tank made of paper sheets is insecure Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face. > or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)? No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is inten…

What about a secret message web widget on a shared computer that uses localstorage as a database and requires the recipient to enter a password to reveal the message, or an offline diary app made with node-webkit that encrypts diary entries? There are lots of uses for JS crypto in cases where information will never leave a local computer. I know that's not what you were saying, but I think it's important to realize that JS has gone beyond remote delivery at this point.

Re: A Criticism of JavaScript Cryptography

#43

Post by rmrfrmrf »

d1str0 wrote: post #15

Why do people use styles like these that push all the content uncomfortably to the sides? 40% of the screen is dedicated to what? The blog title and a link home. Edit: http://i.imgur.com/62l4zCG.png 500% better

The line length in your edit is WAY too long.

Re: A Criticism of JavaScript Cryptography

#44

Post by zAy0LfpBZLC8mAC »

cryptbe wrote: post #34
zAy0LfpBZLC8mAC wrote: post #29

Earlier quoted context omitted.

"they just make the task of programming a crypto library a bit more fun and challenging, not riskier" Seriously? It makes it more difficult to get things right, but the risk of getting it wrong is not increased? And that after you just described how the challenges of JS have already directly led to vulnerabilities? Also, you mostly don't really support your own argument. How exactly does a malicious server not affect…

> Seriously? It makes it more difficult to get things right, but the risk of getting it wrong is not increased? And that after you just described how the challenges of JS have already directly led to vulnerabilities? Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger. > How exactly does a malicious se…

> Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger.

So, it isn't actually a bit more challenging then?

Also, it seems to me like you are at least forgetting timing and possibly other side channels.

> I don't understand this question.

I just can't see any actual scenario where that helps, mostly because it seems to me that the cipher text usually would be a plain-text equivalent, so it doesn't really matter to the attacker whether they have the plain text or the cipher text.

> Because every time I refresh my browser I get a chance to get some trusted code from the server.

So, in other words, you don't have a guarantee?

Other than that, and in general, it seems to me that your argument is somewhat of an equivocation fallacy: You are essentially redefining crypto to include kinda-non-crypto, to then claim that this redefined crypto actually can sensibly be used in browser-side JS, and therefore the arguments against the use of the original crypto are somehow not good advice.

I would think that it is rather obviously implied in most criticism of JS crypto that you are not just executing code that performs a cryptographic primitive, but that you are actually using it to achieve some security goal, and in particular that you are using client-side JS rather than some server-side crypto for some security advantage. That is essentially the implied vague threat model.

So, yeah, it's true that there are uses for crypto primitives that aren't affected by that threat model, because they aren't about security at all. And others that are less affected for various reasons. But it's highly misleading to therefore claim that "most applications aren't affected by that threat model". I'd think that most applications actually are. Except for those built by people who do understand enough of cryptography to not need posts such as the one by matasano. That is to say: Yes, once you yourself can write such an FAQ, you might be able to make use of JS crypto. But at that point, that post won't keep you from doing it anyhow. If you can't, though, chances are you first need to understand every single point made in it.

Re: A Criticism of JavaScript Cryptography

#45

Post by drdaeman »

rmrfrmrf wrote: post #43
d1str0 wrote: post #15

Why do people use styles like these that push all the content uncomfortably to the sides? 40% of the screen is dedicated to what? The blog title and a link home. Edit: http://i.imgur.com/62l4zCG.png 500% better

The line length in your edit is WAY too long.

That depends on its physical size (and viewing distance). Pixels don't really mean anything.

Re: A Criticism of JavaScript Cryptography

#46

Post by zAy0LfpBZLC8mAC »

rmrfrmrf wrote: post #42
jarrett wrote: post #21

Earlier quoted context omitted.

> Is it like saying that a tank made of paper sheets is insecure Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face. > or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)? No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is inten…

What about a secret message web widget on a shared computer that uses localstorage as a database and requires the recipient to enter a password to reveal the message, or an offline diary app made with node-webkit that encrypts diary entries? There are lots of uses for JS crypto in cases where information will never leave a local computer. I know that's not what you were saying, but I think it's important to realize t…

Even though it often isn't spelled out, this is mostly about content-controlled JS loaded from the web, though the language itself also has its problems. And security-wise that app would not be better than one that stored the messages on a server, which only allows you to read them back when you provide the password.

Re: A Criticism of JavaScript Cryptography

#47

Post by jdbernard »

rmrfrmrf wrote: post #42
jarrett wrote: post #21

Earlier quoted context omitted.

> Is it like saying that a tank made of paper sheets is insecure Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face. > or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)? No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is inten…

What about a secret message web widget on a shared computer that uses localstorage as a database and requires the recipient to enter a password to reveal the message, or an offline diary app made with node-webkit that encrypts diary entries? There are lots of uses for JS crypto in cases where information will never leave a local computer. I know that's not what you were saying, but I think it's important to realize t…

The problem is that with the in-browser use case, which is what this whole discussion is about, the code being executed locally came from a remote source. For all of the reasons that Monsanto and the others name it is impossible to ensure that the code does what it claims to. So even if all of your data is stored locally, you have no strong way to ensure that the code that is performing the cryptographic functions is not secretly compromised by an attacker so that, for example, it sends your data in clear to some remote server.

Re: A Criticism of JavaScript Cryptography

#48

Post by cryptbe »

zAy0LfpBZLC8mAC wrote: post #44
cryptbe wrote: post #34

Earlier quoted context omitted.

> Seriously? It makes it more difficult to get things right, but the risk of getting it wrong is not increased? And that after you just described how the challenges of JS have already directly led to vulnerabilities? Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger. > How exactly does a malicious se…

> Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger. So, it isn't actually a bit more challenging then? Also, it seems to me like you are at least forgetting timing and possibly other side channels. > I don't understand this question. I just can't see any actual scenario where that helps, mostly beca…

> So, it isn't actually a bit more challenging then?

More challenging, yes. Riskier, no.

I don't like that Javascript doesn't have native support for big integers (like Python does), or that it stores numbers as floating points in a 52-bit mantissa, but I fail to see why this makes developing crypto code riskier.

> Also, it seems to me like you are at least forgetting timing and possibly other side channels.

Well, I ain't. When you don't control the instructions being executed by the CPU you may have the risks of security-sensitive information leaks. This applies not only to Javascript, but also to all scripting languages. I could say that it also applies to Java, if the methods in its BigInteger class aren't fixed-timing.

In other words using Javascript doesn't make the problem any worse. If you disagree, you're invited to take a look at End-To-End, find a side-channel leak and write an exploit for it. You could earn serious cold cash with that finding.

> I just can't see any actual scenario where that helps, mostly because it seems to me that the cipher text usually would be a plain-text equivalent, so it doesn't really matter to the attacker whether they have the plain text or the cipher text.

I described where it helps in my article.

Re your last point: if doing SSH in a browser isn't crypto I don't know what could be. Is the only thing you consider Javascript crypto encrypted webmail? That's your problem then. You know one wrong use case, and you refuse to admit that there are other legitimate ones.

Edit: remove a few unnecessary sentences.

Edit: some people don't like Javascript crypto so much that they downvote me without saying anything.

Re: A Criticism of JavaScript Cryptography

#49

Post by cryptbe »

tptacek wrote: post #35

I suppose I'm expected to give a full-throated defense of the Matasano post, which I wrote, but I'm not going to. While I don't dislike the post as much as this author appear to, I don't much like it either. I wrote it in a single draft, all at once, as a sort of message board comment I'd write once and maybe in the future refer back to. I didn't promote it on HN and I'm not the reason it keeps getting cited. None of…

> None of this bickering changes a simple truth: when a web mail provider claims to provide "NSA-proof" end-to-end encryption, hosted in Switzerland just to be safe, using software that you don't have to install on your computers at all, then you need to assume that web mail provider can read your email, and so can anyone who can coerce that provider into doing something. If you believe that --- and you should --- then I don't care what you think about the rest of the Matasano article.

This. The whole article could be replaced with this paragraph, and it couldn't be clearer.

Re: A Criticism of JavaScript Cryptography

#50

Post by mcheely »

jarrett wrote: post #8

It's not clear to me if the author is endorsing the use of browser crypto in any particular scenario. Regardless, probably the most common reason for wanting browser crypto is to protect the data before it hits the server, thus protecting against a malicious or compromised server. For example, consider a web-based mail client. You want to send an encrypted message, say via PGP, and you don't want the server to be abl…

Well, now that we have WebRTC, peer-to-peer data transfer is possible in the browser. Perhaps you could imagine a p2p scenario where browser crypto is useful?
Post reply on HN