Live data from Hacker News

A Criticism of JavaScript Cryptography

bren2010.github.io

51–60 of 84 posts

Re: A Criticism of JavaScript Cryptography

#51
post #20

Earlier quoted context omitted.

> so people can learn to use it properly. That's the part to which I'm objecting. As I asked above, what is the proper use of JS crypto? What real-world application do you have in mind where JS crypto's level of security is adequate?

Packaged in a signed browser extension is a good start. Or packaged in a signed desktop app that runs JS to drive the UI (xulrunner, node-webkit, ...). In general, anywhere you aren't basically doing what amounts to an eval() on an external resource (so packaging everything locally, aggressively filtering XSS attacks) can be a good use of JS crypto. I don't think JS crypto itself is the issue. I think the issue is mo…

> Packaged in a signed browser extension is a good start. Or packaged in a signed desktop app that runs JS to drive the UI (xulrunner, node-webkit, ...).

Those are probably acceptable in principle. I should have been more specific: I was referring only to the scenario wherein the webserver provides the JS.

Re: A Criticism of JavaScript Cryptography

#52
post #36
post #19

Earlier quoted context omitted.

> It still might protect you if you won't access server while it's compromised. The end user can't know when that's the case. > Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to. That doesn't provide any assurance to the end user that the JS isn't malicious. Remember, "compromise" doesn't just refer to a drive-by hack…

> > It still might protect you if you won't access server while it's compromised. > The end user can't know when that's the case. This is the entire point of the article. You can't know if it's the case, you can't either with any software distribution. When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server? You just have to trust that the public keys you g…

> When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server?

If you don't take any steps to verify the integrity, then you don't know.

The big difference, as I see it, is that the JS code gets served over and over again to the same clients. Every time you visit the website, it can load a new version of the JS.

Re: A Criticism of JavaScript Cryptography

#53
post #37

Earlier quoted context omitted.

I mean, it is secure against passive adversaries... but that's nit-picking. ChatCrypt has made a large number of mistakes, though, I concur. They don't use HTTPS, it isn't open sourced, and the developer is practically anonymous. I would still maintain that Matasano's article is problematic, though, because it has one of two effects on the reader: 1. The reader is more-than-well convinced on faulty basis that JS cryp…

How about, instead of arguing that readers of an article are more convinced than they should be about something you yourself appear to be convinced of , you put your money where your mouth is and formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography. Give yourself the full benefit of every facility the web programming model gives you, up to the l…

Is that a question? I don't understand the question. "Put your money where your mouth is" doesn't sound like a rebuttal.

I've no idea what you're talking about.

Re: A Criticism of JavaScript Cryptography

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

If you think that's the "simple truth," you either didn't read the article, or you have some piece of information you're not sharing with the rest of us.

You also know something about the "formalisms of HBC" (now redacted), and how it doesn't work with browsers that even scholars don't know about.

I think we'd all appreciate elaboration.

Re: A Criticism of JavaScript Cryptography

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

It still might protect you if you won't access server while it's compromised. It protects you from someone just hacking your server, downloading all the data and getting away. Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to.

Server-side crypto protects you from someone just hacking your server and downloading the data too.

Serving from a smaller and more protected server is interesting, but you'd have to serve at least the HTML as well as every piece of JavaScript (not just the crypto) which doesn't leave too much room for other stuff. And why not just do the crypto server-side on that smaller, more protected server then?

Re: A Criticism of JavaScript Cryptography

#56
post #39
post #5

Earlier quoted context omitted.

No, you don't get to pick your adversaries, but you do get to pick the strongest one you wish to be secure against. Or for that matter, can be secure against. I briefly mentioned Diffie-Hellman key exchanges to provide an example of another common primitive that's only secure against passive adversaries. (DHKEs are typically used in peer-to-peer applications.) Also, if you keep reading, I mention several uses for in-…

I read the whole article and the impression I have is that all the uses you have for in-browser crypto in the current web programming model involve resistance to passive-only attackers .

Then you didn't read the article.

Re: A Criticism of JavaScript Cryptography

#57
post #48

Earlier quoted context omitted.

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

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

For one thing, the IDEA implementation seems to be incorrect. In IDEA, multiplication is defined as multiplication modulo 2^16 + 1, where 0 means 2^16 [3]. However, looking at the multiplication function:

https://code.google.com/p/end-to-end/source/browse/javascrip...

When x == 0 but y != 0, the result of the modular multiplication is always 0, when it should not be. The correct code would be (in glorious C syntax, everything unsigned and 32-bit):

    if(x != 0) {
        if(y != 0) {
            return x*y % 65537; // result fits in 32 bits
        }
        else return 65537 - x; // or 1 - x mod 2^16
    } else return 65537 - y; // or 1 - y mod 2^16
Of course, even if correct this code is still vulnerable to timing attacks (under contrived conditions) [1]. This can be worked around using a little bitwise magic:

    t0  = 65537 - x;
    t1  = 65537 - y;
    t2  = x*y % 65537;
    b0  = -(1 ^ ((x | -x) >> 31)); // 0xfff..ff if x == 0
    b1  = -(1 ^ ((y | -y) >> 31)); // 0xfff..ff if y == 0
    return ((t0&~b0&b1) | (t1&b0&~b1) | (t2&~b0&~b1) | (1&b0&b1))&0xFFFF;
Additionally, the modular inversion seems to be needlessly complicated by using Euclid's algorithm (and I'm not sure it's correct either: it seems not to respect the "0 means 2^16" rule). Use the usual a^(p-2) mod p inversion trick, using an optimal addition chain [2], to make it simpler, constant-time, and possibly faster.

None of this is Javascript's fault, for what it's worth. But I certainly don't expect Javascript to make it any easier to write correct code, much by the contrary.

EDIT: Fixed constant-time code.

[1] https://www.schneier.com/paper-side-channel2.pdf

[2] http://wwwhomes.uni-bielefeld.de/cgi-bin/cgiwrap/achim/scrip...

[3] http://www.isiweb.ee.ethz.ch/papers/arch/xlai-mass-inspec-19...

Re: A Criticism of JavaScript Cryptography

#58
post #37

Earlier quoted context omitted.

How about, instead of arguing that readers of an article are more convinced than they should be about something you yourself appear to be convinced of , you put your money where your mouth is and formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography. Give yourself the full benefit of every facility the web programming model gives you, up to the l…

Is that a question? I don't understand the question. "Put your money where your mouth is" doesn't sound like a rebuttal. I've no idea what you're talking about.

He means crypto from servers can't be trusted. You need something better. You need crypto running in a browser extension.

If I understood your article correctly, when you (bren2013) refer to in-browser crypto you mean crypto code is delivered from the server. But that's not the only in-browser crypto you can get. You can also get in-browser crypto delivered from a browser extension. Under this second definition of in-browser crypto, the following sentence in the article isn't accurate:

there is nothing in-browser crypto can do to defend against active adversaries.

(I admit I didn't read the article thoroughly.)

Re: A Criticism of JavaScript Cryptography

#59
post #52
post #36

Earlier quoted context omitted.

> > It still might protect you if you won't access server while it's compromised. > The end user can't know when that's the case. This is the entire point of the article. You can't know if it's the case, you can't either with any software distribution. When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server? You just have to trust that the public keys you g…

> When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server? If you don't take any steps to verify the integrity, then you don't know. The big difference, as I see it, is that the JS code gets served over and over again to the same clients. Every time you visit the website, it can load a new version of the JS.

Even if you do verify the integrity of the package, then you still can't know for absolute certain that the package maintainer hasn't somehow exposed their private key or been otherwise compromised. You have to trust them.

Re: A Criticism of JavaScript Cryptography

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

using software that you don't have to install on your computers at all

That's the important question: what software do you need to install on a computer to make end-to-end crypto possible for web apps.

(The good kind of crypto that can be trusted.)

Post reply on HN