Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents.<p>The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the server. The server operator, an attacker who can compromise the server, or an attacker who can compromise the SSL connection from the browser to the server can modify the JS to spray plaintext wherever they'd like.<p>Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point.<p>This is not a theoretical weakness. This is exactly happened to both Lavabit and Hushmail. The experiment has been tried and the hand waving didn't amount to much. There's no need (and no excuse!) to try it again.
Please stop upvoting this article, it's misleading at best. It links to the article everyone should read on browser cryptography, the article that says exactly why browser cryptography does not and basically never could work.<p>The article then picks the least important of all security problems, that there isn't (wasn't) a secure way of generating random numbers, acts as if that was an important point and then carries on as if browser cryptography has been solved.<p>In their about page they claim: "As a result, Opal is able to guarantee that the only people who are able to read a secret file are the sender and recipients."<p>This is plainly not true. The people who are able to read these secret files are always those who control the browser. They might claim that they're able to guarantee it because they control the code that is sent by the server, but recent history has shown us that if they were to be forced to break that guarantee, they would not be allowed to let anyone know.<p>So what is their guarantee worth to anyone? Jack shit.
Compiling nacl to javascript is probably a very bad idea without some further analysis. There are almost certainly specialized code constructs that will be lost in the transformation, like branchless code paths, that are designed to prevent certain types of attacks.<p>In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.
<i>Moreover, the LLVM compiler can perform many optimizations during compilation, so the resulting JavaScript is highly optimized.</i><p>Optimization may actually be an argument <i>against</i> C-to-Javascript translated cryptography.<p>NaCl was written in C, according to the constraints and degrees of freedom of a standard C compiler -- which are not the same as those of an interpreted or JiT compiled language.<p>I am not a cryptographer, but source-to-source translation of cryptography is looking for trouble.
Say it with me: <i>browser crypto is bad</i>. But if everyone really wants to build crypto apps using front-end skillsets (which I can understand, because I've done it[0]), go for it! Who says you need a browser? Use Phonegap[1], or node-webkit[2], or appjs[3], or TideSDK[4] (well, not Tide, unless you're a masochist). If you don't want/can't use Node's crypto stuff[5], use SJCL[6] or OpenPGP.js[7] (the last two are <i>not</i> battle-proof libraries, though, because <i>browser crypto is bad</i> so few serious cryptographers have bothered to review them... hopefully that will change if enough people use them outside of the browser). Voila! The convenience of the tools you know, and automatic cross-platform access, without the badness of browser crypto.<p>0. <a href="https://parley.co" rel="nofollow">https://parley.co</a><p>1. <a href="http://phonegap.com/" rel="nofollow">http://phonegap.com/</a><p>2. <a href="https://github.com/rogerwang/node-webkit" rel="nofollow">https://github.com/rogerwang/node-webkit</a><p>3. <a href="http://appjs.com/" rel="nofollow">http://appjs.com/</a><p>4. <a href="http://www.tidesdk.org/" rel="nofollow">http://www.tidesdk.org/</a><p>5. <a href="http://nodejs.org/api/crypto.html" rel="nofollow">http://nodejs.org/api/crypto.html</a><p>6. <a href="http://crypto.stanford.edu/sjcl/" rel="nofollow">http://crypto.stanford.edu/sjcl/</a><p>7. <a href="http://openpgpjs.org/" rel="nofollow">http://openpgpjs.org/</a>
The negative response to this post is over the top.<p>At most, you can say that they overstated their case by neglecting to talk about server trust and using the word "comfortable" in an article about security. :)<p>To address a few red herrings:<p>Saying that no solution is better than a flawed solution is absurd. There's no such thing as impenetrable security. On that basis, we shouldn't bother with HTTPS. For that matter, we shouldn't bother with passwords, either.<p>We do these things because they make attacks incrementally more difficult and thus redirect attackers' efforts to more vulnerable targets, or make it expensive enough not to bother. Every little bit helps.<p>Saying that you can't do this because you have to verify everything on every page load utterly ignores the past decade of development of rich client applications.<p>Saying that you shouldn't do this because it's been tried before also ignores virtually the entire history of technological innovation.<p>This is important problem and constructive criticism from security experts is extremely valuable. But the only "sophistry" I'm seeing here is from the people who can help the most.<p>This is a beta, invite-only app bootstrapped out of the proverbial garage. Their blog post on the technical details missed a few things. If you've ever been in those shoes, you know how easy that is to do. I've seen billion dollar companies do worse. Most of the article was accurate, well-written, and probably helpful to a lot of readers.<p>Help 'em out, don't tear 'em down.
Having the crypto code delivered by the server to provide real-time "end-to-end" security is surely a problem. But, I believe there is a specific use case where even not-so-perfect javascript crypto increases security in a significant way. Imagine you have a system where you want to send encrypted files <i>that are stored on the server</i> to be downloaded later by other users. With javascript public key crypto a la PGP, the user could encrypt this file using keys stored locally. These keys are "uploaded" to the web page when they are needed but not actually sent to the server. The cipher text only is then uploaded to the server and stored. Recipient users can then download the file and decrypt in a similar manner.<p>So what does this help protect against? You are mitigating the situation where the server becomes compromised. In the event your server is compromised, any previously encrypted files are protected <i>as long as the keys are not used again</i> after compromise (since malicious javascript could be delivered to obtain the key).
Came to this thread knowing tptacek would be here, discussing what a terrible idea this was. Got moxie and tptacek. Was not disappointed.<p>This is effectively a me too, but as someone who has spent considerable time researching, understanding, and explaining this problem to customers, let me just say it is a very dangerous thing to do (try to implement a "secure" system on top of JS Crypto in the browser). Moxie and Tom are completely correct and I cringe every time I see one of these projects.<p>And if you aren't convinced after reading this thread: <a href="http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/" rel="nofollow">http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...</a> start here. He covers the topic exhaustively. I feel like anyone arguing about if this is a good idea should do some research and come to the discussion informed. Nate wrote this article over 2.5 years ago.
All browsers already have crypto. Why the fuck are people trying to invent their own when it's built in?<p><a href="http://en.wikipedia.org/wiki/Network_Security_Services" rel="nofollow">http://en.wikipedia.org/wiki/Network_Security_Services</a><p><a href="https://developer.mozilla.org/en-US/docs/Mozilla_Crypto_FAQ" rel="nofollow">https://developer.mozilla.org/en-US/docs/Mozilla_Crypto_FAQ</a><p>All you need is some kind of new "Web Standard" glue between the browser and the JS and do whatever you feel like using the native crypto functionality of the browser. You don't need to add more layers of complexity. But you can add a small bit of abstraction to what is already there.
We implemented a system where the key used to encrypt messages is generated in the browser and never leaves the browser. This ensures even we cant decrypt messages. The downside is the end user has to remember a 'Room Secret Key'.<p>You can read more here: <a href="https://www.tesla.im/#encrypted_rooms" rel="nofollow">https://www.tesla.im/#encrypted_rooms</a><p>We are just a few weeks into beta and have only a few hundred users. Been working well so far. However it's too early for us to give solid validations.