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