4 ms·

JSCrypto — Fast symmetric cryptography in Javascript

63 points by chrislloyd 17y ago

alecco 17y ago
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 17y ago
  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 17y ago
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 17y ago
  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-public-key-encryption-in-php-and-javascript http://stackoverflow.com/questions/1528012/secure-login-publ... .
  - tptacek 17y ago
    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.
  - stuff4ben 17y ago
    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 17y ago
      $30 is expensive; SSL certs have been free for a little while: http://www.startssl.com/?app=1 http://www.startssl.com/?app=1
  - DenisM 17y ago
    SO should ban all security-related questions. There is too much misinformation and wrong answers get marked as "resolution": http://stackoverflow.com/questions/1702661 http://stackoverflow.com/questions/1702661
- bmm6o 17y ago
  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?
niyazpk 17y ago
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.
markpercival 17y ago
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 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 17y ago
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 17y ago
  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.
pierrefar 17y ago
This could be an awesome combination with Node.js.
- jacobolus 17y ago
  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.
- jazzychad 17y ago
  Then you may enjoy node-crypto: http://github.com/waveto/node-crypto http://github.com/waveto/node-crypto
  - pierrefar 17y ago
    Thanks! Added to my collection of node.js things.
tdmackey 17y ago
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-crypto-flaws/ 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 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 17y ago
  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 17y ago
    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.

63 points by chrislloyd 17y ago

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 17y ago
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 17y ago

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 17y ago
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-public-key-encryption-in-php-and-javascript http://stackoverflow.com/questions/1528012/secure-login-publ... .
- tptacek 17y ago
  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.
- stuff4ben 17y ago
  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 17y ago
    $30 is expensive; SSL certs have been free for a little while: http://www.startssl.com/?app=1 http://www.startssl.com/?app=1
- DenisM 17y ago
  SO should ban all security-related questions. There is too much misinformation and wrong answers get marked as "resolution": http://stackoverflow.com/questions/1702661 http://stackoverflow.com/questions/1702661
bmm6o 17y ago
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?

niyazpk 17y ago

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.

markpercival 17y ago

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 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 17y ago

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 17y ago
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.

pierrefar 17y ago

This could be an awesome combination with Node.js.

jacobolus 17y ago
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.
jazzychad 17y ago
Then you may enjoy node-crypto: http://github.com/waveto/node-crypto http://github.com/waveto/node-crypto
- pierrefar 17y ago
  Thanks! Added to my collection of node.js things.

tdmackey 17y ago

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-crypto-flaws/ 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 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 17y ago
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 17y ago
  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.