

JSCrypto — Fast symmetric cryptography in Javascript - chrislloyd
http://crypto.stanford.edu/sjcl/

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

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

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

~~~
caf
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...](http://stackoverflow.com/questions/1528012/secure-login-public-key-
encryption-in-php-and-javascript) .

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

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

------
markpercival
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 :)

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

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

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

------
tdmackey
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-...](http://rdist.root.org/2009/08/06/google-tech-talk-on-
common-crypto-flaws/) 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.

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

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

------
pierrefar
This could be an awesome combination with Node.js.

~~~
jazzychad
Then you may enjoy node-crypto: <http://github.com/waveto/node-crypto>

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

