A Criticism of JavaScript Cryptography
bren2010.github.io
bren2010.github.io
The Matasano post is here:
http://matasano.com/articles/javascript-cryptography/
Perhaps the most objectionable thing about the Matasano article is title. Otherwise it does a very good job of criticizing a particular way of engineering web cryptography that is, for lack of a better term, total bullshit. But is the approach criticized in the Matasano post used in the real world?
Let's try an experiment! Go to google.com and type in "encrypted chat"
If your results are similar to mine, one of the top 3 results will be "chatcrypt.com". Let's read the "How It Works?" page:
> Most people thinks that if a website uses a HTTPS connection (especially with the green address bar) then their "typed-in" informations are transmitted and stored securely. This is only partially true. The transmission is encrypted well, so no third party can sniff those informations, but there is no proof that the website owners will handle them with maximum care, not mentioning that the suitable laws can enforce anyone to serve stored data for the local authorities.
Okay, so this site attempts to implement end-to-end encryption in a web browser. Except... what's the problem? Oh, it looks like chatcrypt.com isn't served over HTTPS. In fact, if we try to visit the site over HTTPS, it doesn't work at all.
chatcrypt.com claims to keep your traffic secure using end-to-end cryptography implemented in JavaScript, except the JavaScript is being served in plaintext and is therefore easily MitMable.
Top 3 Google result for "encrypted chat"
Is the Matasano post that unreasonable? (besides the title) It pretty much describes that sort of site to a tee.
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 crypto should never be used.
2. The reader is still adamant on continuing their project, but is now alienated from a source that could have offered a plethora of helpful advice. (Example: "Please, for all that is good, use HTTPS.")
Of course, nothing will prevent the occasional surfacing of bad crypto, but their article certainly doesn't help any of its causes.
I've no idea what you're talking about.
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.)
Let me break that down for you:
1) formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography.
1.a) Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions.
2) What's a system like (1) that has worked well, and would be resilient to a determined adversary?
So, he's claiming to have shown that content-controlled browser javascript crypto is worse that useless because it allows good people to inadvertently leak secrets. All you have to do to prove him wrong is just tell him a use case where it would make sense and then cite an example where that worked well* and would be resilient to a determined* adversary.
So, all you have to do is say "chatcrypt.com's use case makes sense and chatcrypt rocks. Here I show that it is unbreakable until long after the stars cool, and no amount of kneecap cryptography will lessen the adversery's burden."
* He's giving you two wiggle words already, you can define them however you'd like.
A construction or implementation is secure if an adversary, given a certain level of power, is unable to achieve a given objective. The level of power an adversary is assumed to have and their ultimate objective is called the threat model.
If a new construction is secure under a new threat model that either increases the amount of power an adversary can have or makes the adversary's objective broader, the new construction is said to have a higher level of security.
This is what we need more in security discussions. So many discussions, here on HN but also, well, everywhere, are really misunderstandings about which threat model to assume. People get into hot-headed fights about whether some solution somewhere is or is not "secure", when really all they disagree about is which definition of "secure" to use.
Well done! I propose that security related blog posts take some time out to casually define these terms over and over again, for a while, until we can all just assume them known and be done with all the vague imprecise nonsense.
I do not believe this is a dimension that has been missing from previous discussions, but perhaps you can use the search bar below to find a debate about JS crypto where it was missing and where the result was misleading to readers.
Oh come on, was that sneer called for? If you really feel that none of the security discussions here on HN are getting way out of hand over what's really a misunderstanding on some basic assumptions, then you haven't been looking. Note, I didn't say "JS crypto discussions", I said "security discussions".
In fact, I'm mostly referring to the kinds of discussions that did not start as a security topic, but evolved into them. There, there's often people like me, who care about security but who are far from experts, and these people (myself included) often mix stuff up. Clearing out definitions and which threat model to assume would really help in such discussions. I thought that this blog post did that in a very clear and non-opinionated way in that little paragraph there, so I complimented it.
Is that really so bad?
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.
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.
Incidentally, the "now redacted" in the parent comment refers to three bullets I had written in the grandparent comment and left for four minutes before realizing that objecting in detail to this person's blog post more or less amounted to making a full-throated defense of the Matasano post. Which, like I said, I'm not in love with either.
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.)
So, if that is the best in-browser crypto can do, then it is still basically useless, unless you get to choose your adversary. And "active adversary" software is off-the-shelf tech, not some sort of bizarre thing only the NSA has access to. Active adversary is the lowest baseline of attack worth talking about.
Also, if you keep reading, I mention several uses for in-browser crypto.
Saying "I'm secure against passive attackers" doesn't mean that you're safe doing anything on your "secure" channel, because the bar for active attack is so low that that's hardly saying anything. You can be secure against "passive attackers", but you still can't verify that you haven't been attacked, in general. A definition of security in which a user blithely sticks sensitive data on a channel, unconcerned about whether the channel was attacked, is a useless definition of security... by definition, we're not talking about a user concerned with security, of any kind.
If we are talking about a security scenario where the equivalent of "active attack" is actually quite difficult and it takes a nation-state's resources, I'd be happy to discuss this argument. We've historically used some encryption at points in time where technically brute forcing it was feasible for very large entities, for instance. But the bar for active attack on the web is low here, very, very low.
You can't verify that someone isn't MiTM'ing with a stolen certificate. You can't verify that the CA hasn't been coerced into forging a valid certificate. You can't verify that your government hasn't ordered that computer manufacturers install surveillance devices. That doesn't mean that the internet is unusable.
Some things are vulnerable to active attacks, and if they were attacked, nobody would know. Every cryptographer knows this. It's not a big deal.
Selecting a threat model is all well and good, but if you select an artificially easy threat model to defend against then you're not really helping users (in this case, helping them against random evil ISPs?)
You expected to see a Perfectionist Fallacy argument, so you saw one. But it's not, because "active attacks" in this context don't require anything close to "perfection" to achieve. It's exactly the other way around... it requires near perfection to prevent them in the real world!
Because a solipsistic worldview is, perhaps, irrelevant to everyday life, we begin to operate on assumptions based on information that's infeasible for us to know for certain. This is what you must do to talk about security on the Internet: limit the domain of the problem by making assumptions about the Internet's infrastructure. You're right that it will never be possible to share a secret on the Internet without risk, that's not the point of this article or any others that indicate the flaws of JavaScript cryptography.
I don't understand crypto very well so I wish the article explained things in simpler terms. Shorter would be better for me.
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 able to read it, even if the server is evil. You'd like to be able to do the PGP encryption 100% in-browser, with no browser plugins or extensions necessary.
I think that's the most common category of use-case for browser crypto. Unfortunately, it's one where browser crypto plainly doesn't work. The whole point here is to defend against an evil server, but if the server is evil, it will send you evil crypto JS. TLS doesn't help you. Nobody's impersonating the server or altering the JS file in transit. You're getting an authentic copy of the JS file from the real server. It just happens to be an authentic copy of an evil JS file.
Given that, what can you do with browser crypto, practically speaking?
Please read the article again carefully. I think you'll find the answers to your questions.
Yes, it is important to be aware that security is always relative to a threat model, and at times it can lead to confusion when threat models are not made explicit. That does not mean, though, that it's necessarily wrong to imply a sensible threat model in a given context, and to just call something "insecure" without any further explicit qualifications if it does not protect against a reasonable minimal threat model that essentially everyone essentially always has to face.
Also, it's questionable whether you can call the NSA's mass surveillance a passive attack, given that QUANTUM INSERT exists and was used, in order to attack foreign communications infrastructure.
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.
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 intended for. Whereas, JS crypto is presumably intended to protect users when the remote server can't be trusted. (What else would it be for?) It can't offer such protection.
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?
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 more pulling your code from an external, ultimately untrusted source. You can do this in many languages, and it's equally a Terrible Idea in all of them. Granted, some things auto-update and can verify an update via a packaged public key, but the model of continuously downloading code on each run, while easier on app developers, is a ticking time bomb for crypto.
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.
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.
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. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.
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 got are the right ones, and their private keys have not been stolen.
So what the author is saying is that regarding that aspect web crypto is at roughly the same level.
The big problem of course is that there is evidence that the whole CA system is much less reliable than the old GPG signing party system.
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.
Yes. I didn't say that user can know if he is protected. Just that he is when this condition is met.
> Remember, "compromise" doesn't just refer to a drive-by hack. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.
Didn't you just do what OP criticizes? I said it has value in some scenarios assuming some threat model and you countered by showing that it doesn't protect you in some other threat model. When you don't trust the third party the only way to protect yourself is never rely on what they control. Especially never run their software on your machine in a way that has access to your secret data. In that scenario any type of encryption other than built in the browser binary (not supported? risky?) or better yet outside of browser (cumbersome) is pointless.
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?
You are right.
> which doesn't leave too much room for other stuff.
Well... HTML and JS can be light and static. Backend stuff is what might require multiple servers, databases and lots of people involved.
> And why not just do the crypto server-side on that smaller, more protected server then?
Because you'd have to pass all of the data that you wan't to secure through it. Besides server-side crypto is surely more complicated and would need more people involved especialy with large volume of data than just serving static files.
This ability to mix offline and online content is something that I think has a lot of potential to improve client-side encryption. Specifically, client-side encryption coupled with an unhosted webapp[1].
I've been exploring this potential for my byoFS[2] project, and made an example end-to-end encrypted chat demo[3]. You can request the app anonymously (or even save it and open it locally). The app then lets the user connect an online datastore (e.g. Dropbox) to save the encrypted chats.
This separates who serves the anonymous static webapp and the authenticated datastore, and makes it much harder to target a javascript attack (the most common attack from the Snowden leaks).
[1] - https://unhosted.org/
Some more information from the security page [2]:
The browser extension provides improved security by verifying the integrity of the files served by the server. The verification is done using two factors:
- Cold storage signature verification: In addition to SSL, static files (html/css/javascript) are signed using standard Bitcoin message signatures, with a private key that is stored offline and encrypted. This ensures that the content served from the webserver was not tampered with by a third party.
- Comparing against the code on GitHub repository: The source code from the GitHub repository is built on Travis-CI and the resulting hashes are published publicly on Travis's job page. The extension ensures that the content served by the webserver matches the open-source repository on GitHub.
If an attacker gains control over the web server, he still only has access to information the web server already knows (which is very little). To get sensitive information, he would have to modify the client-side code to send back more data to the server.
For an attacker to successfully mount such an attack against someone with the browser extension, he would have to:
- Gain access to the web server.
- Gain access to the personal computer of a developer with commit access to the GitHub repository. [3]
- Commit his changes to the public GitHub repository, where they can be seen by anyone. [3]
- Gain physical access to the offline machine with the private key and know the passphrase used to encrypt it.
[2] https://www.bitrated.com/security.html#browser-extension
[3] That's assuming that GitHub and Travis-CI are themselves secured. Gaining access to any of them would make those steps unnecessary.
so, the NSA needs only to publish their hashes here (or send them only to specific clients or insert them MTM style).
Alas, client-side JavaScript doesn't speak DNS. You'd have to go through a server, which would mean you'd lose anything you might gain.
Edit: http://i.imgur.com/62l4zCG.png 500% better
- Statically encrypt and publish content on HTTP server - Transmit these via HTTP to an iframe component at client browser - transmit decryption and key routines using HTTPS. - HTTP-iframe locally sends message to HTTPS-iframe via window.postMessage() - HTTPS-iframe decrypts content (with pre-shared key) and renders it on page
I understand the strong reaction to the actions of the NSA, but all this is doing is providing the appearance of security while not making it any more difficult for adversaries like the NSA.
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 "crypto browser apps"? How does staying out of scope for PCI DSS have anything to do with security (except maybe demonstrating that PCI DSS is crap because it can so easily be circumvented)? Also, in what kind of scenario would leaking info in a referer be a problem, but leaking the same info in encrypted form would not? And how do you guarantee that your verification code is loaded fresh from the server once your application has been compromised in a browser?
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 server not affect "crypto browser apps"?
I didn't claim that malicious servers won't be able to affect crypto browser apps. What I said is that in these apps you have to trust the server already, so it doesn't make sense to consider them untrusted.
> How does staying out of scope for PCI DSS have anything to do with security (except maybe demonstrating that PCI DSS is crap because it can so easily be circumvented)?
It's exactly the point. When people say "javavascript crypto is harmful" they don't consider use cases where it's really useful, even just to circumvent PCI DSS.
> Also, in what kind of scenario would leaking info in a referer be a problem, but leaking the same info in encrypted form would not?
I don't understand this question.
> And how do you guarantee that your verification code is loaded fresh from the server once your application has been compromised in a browser?
Because every time I refresh my browser I get a chance to get some trusted code from the server.
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.
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.
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
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;
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...
Edit: I've just filed https://code.google.com/p/end-to-end/issues/detail?id=82. We can discuss the problems of IDEA there. Thanks!
Please explain. Is it that it is more challenging, but in a way that it's not more difficult to get it right (what exactly is the challenge then?) or is it not riskier because the higher probability of getting it wrong does not decrease the probability of getting it right (how exactly do you increase one probability without decreasing the probability of the negated case?)?
> This applies not only to Javascript, but also to all scripting languages.
So, a bridge built from matches isn't any more robust than a bridge built from toothpicks, therefore building bridges from toothpicks is a good idea (nevermind that other people are using reinforced concrete for bridge construction)? I'm sorry, but I can't quite follow your argument.
> 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.
You are not seriously bringing forward the "secure-because-hacking-contest" argument, are you?
> Re your last point: if doing SSH in a browser isn't crypto I don't know what could be.
Sure it is, but it still is rather obviously not what those posts are primarily attacking. Or maybe it is, if anyone claims or implies that this "SSH-client in a browser" is any more secure than "browser frontend to SSH-client on the server". Which I think is kinda the whole reason for its existence? Performance- and complexity-wise, I doubt that it makes any sense at all to implement the SSH protocol itself in the browser in that case, vs. using a native SSH client on the server.