From the paper:

  Our approach. In our Javascript implementation we propose
  a different approach that keeps the code small and speeds up
  encryption/decryption. Instead of embedding tables in the
  code, our library contains code that precomputes all tables
  on the browser before encryption or decryption begins. Since
  code to precompute the tables is much smaller than the tables
  themselves, we keep the library size small. We reap the benefits
  of precomputed tables by quickly building the tables on the
  browser before the first encryption. The only values we hardcode
  are the 10 round constants, which are 28 bytes total.

  Precomputing the tables takes about 0.8ms on Google Chrome and about 8ms
  on Internet Explorer 8. Because this saves several KB of code,
  it is nearly as fast to precompute the AES tables as it would
  be to load them from disk. Moreover, computing the tables in
  the browser is far faster than downloading them over the network.

Amazing implementation.

Another way to think of it: because tables used in encryption algorithms are often very difficult to compress with conventional algorithms, deriving the tables from their pre-compute algorithms is a much more efficient means of compression.

This is a very cool library that is going to be abused far more often than used correctly. In particular:

* In online Internet applications, it can only be delivered safely on pages for which every resource is delivered over HTTPS. Most developers aren't going to see the point of using both HTTPS and JSCrypto. The ones who choose simply to use JSCrypto have totally insecure applications.

* For the task of creating applications with Tarsnap-like insulation between the server and customer data (ie, a backup system where the server can't read your data), this library won't work; any application that delivers this library can in a myriad of subtle and undetectable ways sabotage its security.

Witness: An unending series of Stackoverflow questions on doing encryption in Javascript, all of them much like this one: http://stackoverflow.com/questions/1528012/secure-login-publ... .

Ow, my brain. People forget how hostile an environment Javascript is for trusted code. It's not just that you can stage an elaborate man-in-the-middle attack; it's that anything that allows you to run code in the same JS instance can sabotage the encryption. That includes MITM, but it also includes XSS and Javascript injection, JSON injection, and it applies to every source of script and DOM content that builds up the page.

SO should ban all security-related questions. There is too much misinformation and wrong answers get marked as "resolution": http://stackoverflow.com/questions/1702661

The most revealing thing to me was that you can buy an SSL certificate for as little as $30 these days (GoDaddy). It's been a while since I've had to order one for my company, but I seem to recall it costing several hundred dollars the last time I did it.

$30 is expensive; SSL certs have been free for a little while: http://www.startssl.com/?app=1

That's all true, from the client end you cant trust this to stop the server end from snooping your data, but there seems to be a class of problems this approach _does_ solve. Where the guy running the server wants better than just plausible deniability about knowing what his users are storing. It can't guarantee to the "customer" that the "server" can't read his unencrypted data, but it'd probably be as close as you could get to a guarantee for the guy legally responsible for the "server" that he couldn't read (and hence be in any way responsible for) the unencrypted customer data...

I actually have exactly that in one of my products http://www.memengo.com All content is delivered over HTTPS, encryption is in Javascript on the client side. Yes, the user must trust me not to alter the JS code behind their back, but the same applies for any native app that could auto-update and is not guarded by outgoing firewalls. Which is most of them.

The reason why data is encrypted is that database theft (e.g. backup theft) is not a disclosure of data.

Most desktop applications don't automatically update themselves every time you use them.

A lot of apps check for updates on each start, and most users will install an update when prompted. Not everyone, true, but let's talk statistics for now.

Whether developer himself is malicious or his auto-update is hacked, it's a vector to inject harmful code to the user-side environment.

Statistically, there is no practical difference in security of the user's data between a native app and a web app.

I read the title, and optimistically hoped that they were talking about server-side javascript. What are the problems for which symmetric crypto in the browser is the correct solution?

I've been using the table method with Gibberish AES, although I don't compile the tables, I'm not sure the size benefit is that significant.

http://github.com/markpercival/gibberish-aes

The advantage of mine is that it's fully OpenSSL compatible and plenty fast. 20k of text on Chrome take .064 seconds to decode and encode.

But I love the idea of compile on load, might have to steal it :)

Of course, "fast" is very relative. A quick test with 'openssl speed' on my laptop (two years old, power-saving mode cutting performance in half, using one of two cores) shows OpenSSL is roughly a hundred times faster than this library on Firefox.

Which is not to say that getting to this point is not an achievement; JavaScript isn't exactly the best language to implement cryptographic algorithms in.

If you just added support for some primitives (like some sort of 32BitArray or 64BitArray) then you'd probably be able to get within an order of magnitude of OpenSSL.

JavaScript has come a long way.

It feels weird that these days when I am trying out some fun projects or algorithms, I prefer using JavaScript to build a prototype if possible. JavaScript is fast enough for my small computing needs & It does not require anything else to run other than a browser.

WebSockets, HTML5 (Canvas + Web Storage etc)... Really exciting.

I am typically one of the opinion that if you are doing crypto in javascript you are doing it wrong. Talks like http://rdist.root.org/2009/08/06/google-tech-talk-on-common-... provide insight and let us not forget http://chargen.matasano.com/chargen/2006/4/28/oh-meebo.html Besides it is very difficult to have javascript return sutiably random numbers cross platform. If you need to encrypt browser traffic use ssl instead of some half-assed pseudo-secure javascript mess.

Sorry JSCrypto team, while your implementation is awesome and all, you are doing it wrong.

While your caveat is true for people using this on the client side, what about people using javascript on the server side ?

Though its probably best to use C wrappers to established crypto libraries on the server side, we shouldn't underestimate the ease of use which comes with using pure javascript libraries.

There's nothing intrinsically unsafe about serverside Javascript crypto, but there's something practically unsafe about directly using AES anywhere.

In the meantime, serverside Javascript as a rule has access to better native AES code. The browser definitely seems like the motivating use case here.

This could be an awesome combination with Node.js.

Then you may enjoy node-crypto: http://github.com/waveto/node-crypto

Thanks! Added to my collection of node.js things.

It would be much better to write/wrap C/C++ code to work with Node.js; the main reason this library is useful is that browsers don't expose crypto APIs, and in-browser javascript can't call down to faster code.