9 ms·

A Criticism of JavaScript Cryptography

78 points by Agrosis 12y ago

cryptbe 12y ago
Interesting coincidence. I just wrote http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-is-useful.html http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-i..., in which I explain the threat model implied in the Matasano's article doesn't apply to most applications.
- zAy0LfpBZLC8mAC 12y ago
  "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 "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?
  - cryptbe 12y ago
    > 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 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.
    - zAy0LfpBZLC8mAC 12y ago
      > 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.
      - cryptbe 12y ago
        > 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.
- tptacek 12y ago
  This is a fantastic post that deserves to be on the front page of HN.
jerf 12y ago
One problem with the "passive adversary" attack is that even if the nonce+HMAC protocol defeats the passive adversary, you as a user have no way of verifying whether or not your adversary is passive. Or whether they exist, or, indeed, anything about them, as in the real world, you don't get to pick your adversaries. The user needs a way to determine whether the connection is secure before they can trust it, because they can't (correctly) assume that only passive adversaries exist. 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.
- bren2013 12y ago
  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-browser crypto.
  - jerf 12y ago
    Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the universe ("I am only being attacked by passive attackers") in order to declare your system "more secure". 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.
btreecat 12y ago
I really enjoyed reading this. Certainly put the browser security model in a new perspective for me.
deleted 12y ago
[deleted]
skrebbel 12y ago
Wow. 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.
- tptacek 12y ago
  This sounds important, but the distinction between "passive" and "active" attackers has come up in every discussion of JS crypto I can remember on HN, and indeed in every discussion of TLS (see, for instance, every discussion of why certificate authorities are necessary and why self-signed certificates are insecure "despite using exactly the same cryptography as CA-signed certificates"). 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.
  - skrebbel 12y ago
    > 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?
jarrett 12y ago
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 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?
- bren2013 12y ago
  lol, This is exactly what I was trying to stop people from doing! I'm not endorsing or damning it--I'm talking about it sensibly and objectively so people can learn to use it properly. Please read the article again carefully. I think you'll find the answers to your questions.
  - zAy0LfpBZLC8mAC 12y ago
    While you might be formally correct, your criticism still seems about as sensible as criticising someone who said "a tank made of paper sheets is not secure" because they failed to specify a threat model. After all, such a tank would be secure against a paralyzed attacker without weapons. 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.
d1str0 12y ago
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 http://i.imgur.com/62l4zCG.png 500% better
- tptacek 12y ago
  Because there is an optimum range of characters per line for readability.
- rmrfrmrf 12y ago
  The line length in your edit is WAY too long.
  - drdaeman 12y ago
    That depends on its physical size (and viewing distance). Pixels don't really mean anything.
bascule 12y ago
I thought this was a good post, but I wasn't impressed with the criticisms of other blog posts. Okay, perhaps I'm biased, because I wrote one of them, but how about I try to defend the other? The Matasano post is here: http://matasano.com/articles/javascript-cryptography/ 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.
- bren2013 12y ago
  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 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.
deleted 12y ago
[deleted]
diafygi 12y ago
One aspect of in-browser functionality OP mentions is "offline". However, browsers are pretty cool in that they can mix offline and online. You can open a local html file and it can then make online requests. Alternatively, you can request an html file online that then can access local 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/ https://unhosted.org/ [2] - https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS [3] - https://diafygi.github.io/byoFS/examples/chat/ https://diafygi.github.io/byoFS/examples/chat/
bugmen0t 12y ago
Attesting software (i.e. JavaScript, even from third parties) might be possible if https://w3c.github.io/webappsec/specs/subresourceintegrity/ https://w3c.github.io/webappsec/specs/subresourceintegrity/ gains traction.
nadaviv 12y ago
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 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. [1] https://www.bitrated.com/ https://www.bitrated.com/ [2] https://www.bitrated.com/security.html#browser-extension 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.
- trhway 12y ago
  >The source code from the GitHub repository is built on Travis-CI and the resulting hashes are published publicly on Travis's job page. so, the NSA needs only to publish their hashes here (or send them only to specific clients or insert them MTM style).
- zAy0LfpBZLC8mAC 12y ago
  So, you have just made GitHub the trusted third party for the world? After the X.509 CAs have so successfully protected us all these years without a single compromise or other security blunder and nobody is working on ways to get rid of those single points of failure, especially not the people behind certificate patrol or monkey sphere, that must be the best security model ever!
notblahbl4hblah 12y ago
No such thing as a secure keystore? He needs to look harder. Aside from hardware which is tamper proof... which exists in smart cards and TPM chips... most operating systems use file system ACL's. Yes running as "root" means you can get the keys... you have to protect them...
- notblahbl4hblah 12y ago
  Why did this get downvoted? No one even replied!
  - jdbernard 12y ago
    You are right, and the fact that people are just dismissing you out of hand is frightening. It shows a lack of even the interest to understand how off-base they are.
tptacek 12y ago
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 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.
- cryptbe 12y ago
  > 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.
- bren2013 12y ago
  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.
  - tptacek 12y ago
    This comment appears to be totally unresponsive to mine. 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.
cybernytrix 12y ago
Can any of you comment on my scheme described here: http://ashkash.github.io/ajaxcrypt/index.html http://ashkash.github.io/ajaxcrypt/index.html This should resist even active adversaries: - 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
jdbernard 12y ago
Ten years from now, when web security is even more laughable and anemic than it already is, some of us are going to remember discussions like these where application developers at large ignored the warnings from the established crypto community. Some of us are old enough already to remember this pattern happening before. 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.
- notblahbl4hblah 12y ago
  Yep. This whole NSA thing has forced a new generation to start reading Applied Cryptography...or at least make it plain that they need to.
notblahbl4hblah 12y ago
I think that the main reason that people keep wanting to do this is that web developers would like to work on this problem but don't have skills that are applicable immediately. It's going to require a great deal of learning on most of their parts that is at least as daunting as becoming a good front-end developer to use existing crypto libraries well...much less engineer new cryptosystems. That would be the difference between being able to code and being able to write a high quality optimizing compiler, for instance. With study and hard work you can use the fruits of the crypto community well...but you have to start by realizing where you are starting from. In browser javascript isn't just another programming language and runtime that's completely akin to c and the c runtime. The Matasano article does a great job of describing why.

78 points by Agrosis 12y ago

Interesting coincidence. I just wrote http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-is-useful.html http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-i..., in which I explain the threat model implied in the Matasano's article doesn't apply to most applications.

zAy0LfpBZLC8mAC 12y ago
"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 "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?
- cryptbe 12y ago
  > 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 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.
  - zAy0LfpBZLC8mAC 12y ago
    > 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.
    - cryptbe 12y ago
      > 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.
tptacek 12y ago
This is a fantastic post that deserves to be on the front page of HN.

jerf 12y ago

One problem with the "passive adversary" attack is that even if the nonce+HMAC protocol defeats the passive adversary, you as a user have no way of verifying whether or not your adversary is passive. Or whether they exist, or, indeed, anything about them, as in the real world, you don't get to pick your adversaries. The user needs a way to determine whether the connection is secure before they can trust it, because they can't (correctly) assume that only passive adversaries exist. 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.

bren2013 12y ago
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-browser crypto.
- jerf 12y ago
  Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the universe ("I am only being attacked by passive attackers") in order to declare your system "more secure". 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.

btreecat 12y ago

I really enjoyed reading this. Certainly put the browser security model in a new perspective for me.

deleted 12y ago

[deleted]

skrebbel 12y ago

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

tptacek 12y ago
This sounds important, but the distinction between "passive" and "active" attackers has come up in every discussion of JS crypto I can remember on HN, and indeed in every discussion of TLS (see, for instance, every discussion of why certificate authorities are necessary and why self-signed certificates are insecure "despite using exactly the same cryptography as CA-signed certificates"). 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.
- skrebbel 12y ago
  > 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?

jarrett 12y ago

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

bren2013 12y ago
lol, This is exactly what I was trying to stop people from doing! I'm not endorsing or damning it--I'm talking about it sensibly and objectively so people can learn to use it properly. Please read the article again carefully. I think you'll find the answers to your questions.
- zAy0LfpBZLC8mAC 12y ago
  While you might be formally correct, your criticism still seems about as sensible as criticising someone who said "a tank made of paper sheets is not secure" because they failed to specify a threat model. After all, such a tank would be secure against a paralyzed attacker without weapons. 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.

d1str0 12y ago

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 http://i.imgur.com/62l4zCG.png 500% better

tptacek 12y ago
Because there is an optimum range of characters per line for readability.
rmrfrmrf 12y ago
The line length in your edit is WAY too long.
- drdaeman 12y ago
  That depends on its physical size (and viewing distance). Pixels don't really mean anything.

bascule 12y ago

I thought this was a good post, but I wasn't impressed with the criticisms of other blog posts. Okay, perhaps I'm biased, because I wrote one of them, but how about I try to defend the other? The Matasano post is here: http://matasano.com/articles/javascript-cryptography/ 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.

bren2013 12y ago
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 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.

deleted 12y ago

[deleted]

diafygi 12y ago

One aspect of in-browser functionality OP mentions is "offline". However, browsers are pretty cool in that they can mix offline and online. You can open a local html file and it can then make online requests. Alternatively, you can request an html file online that then can access local 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/ https://unhosted.org/ [2] - https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS [3] - https://diafygi.github.io/byoFS/examples/chat/ https://diafygi.github.io/byoFS/examples/chat/

bugmen0t 12y ago

Attesting software (i.e. JavaScript, even from third parties) might be possible if https://w3c.github.io/webappsec/specs/subresourceintegrity/ https://w3c.github.io/webappsec/specs/subresourceintegrity/ gains traction.

nadaviv 12y ago

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 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. [1] https://www.bitrated.com/ https://www.bitrated.com/ [2] https://www.bitrated.com/security.html#browser-extension 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.

trhway 12y ago
>The source code from the GitHub repository is built on Travis-CI and the resulting hashes are published publicly on Travis's job page. so, the NSA needs only to publish their hashes here (or send them only to specific clients or insert them MTM style).
zAy0LfpBZLC8mAC 12y ago
So, you have just made GitHub the trusted third party for the world? After the X.509 CAs have so successfully protected us all these years without a single compromise or other security blunder and nobody is working on ways to get rid of those single points of failure, especially not the people behind certificate patrol or monkey sphere, that must be the best security model ever!

notblahbl4hblah 12y ago

No such thing as a secure keystore? He needs to look harder. Aside from hardware which is tamper proof... which exists in smart cards and TPM chips... most operating systems use file system ACL's. Yes running as "root" means you can get the keys... you have to protect them...

notblahbl4hblah 12y ago
Why did this get downvoted? No one even replied!
- jdbernard 12y ago
  You are right, and the fact that people are just dismissing you out of hand is frightening. It shows a lack of even the interest to understand how off-base they are.

tptacek 12y ago

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

cryptbe 12y ago
> 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.
bren2013 12y ago
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.
- tptacek 12y ago
  This comment appears to be totally unresponsive to mine. 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.

cybernytrix 12y ago

Can any of you comment on my scheme described here: http://ashkash.github.io/ajaxcrypt/index.html http://ashkash.github.io/ajaxcrypt/index.html This should resist even active adversaries: - 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

jdbernard 12y ago

Ten years from now, when web security is even more laughable and anemic than it already is, some of us are going to remember discussions like these where application developers at large ignored the warnings from the established crypto community. Some of us are old enough already to remember this pattern happening before. 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.

notblahbl4hblah 12y ago
Yep. This whole NSA thing has forced a new generation to start reading Applied Cryptography...or at least make it plain that they need to.

notblahbl4hblah 12y ago

I think that the main reason that people keep wanting to do this is that web developers would like to work on this problem but don't have skills that are applicable immediately. It's going to require a great deal of learning on most of their parts that is at least as daunting as becoming a good front-end developer to use existing crypto libraries well...much less engineer new cryptosystems. That would be the difference between being able to code and being able to write a high quality optimizing compiler, for instance. With study and hard work you can use the fruits of the crypto community well...but you have to start by realizing where you are starting from. In browser javascript isn't just another programming language and runtime that's completely akin to c and the c runtime. The Matasano article does a great job of describing why.