6 ms·

Stanford's Javascript Crypto Library

70 points by siculars 16y ago

a1g 16y ago
nice I've been waiting for something like this. thank you.
- tptacek 16y ago
  Thank you in advance for putting my kids through college.
apike 16y ago
Sounds interesting. What does tptacek say?
- siculars 16y ago
  The main page does talk specifically about issues with running crypto in the browser: "Unforunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." Nevertheless, I wonder what tptacek thinks about the implementation.
  - ErrantX 16y ago
    What it should probably say is: "Unforunately, this should not be considered a secure alternative to desktop applications because it is not feasible at all to protect against code injection, malicious servers and side-channel attacks." The unfortunate thing is that however cleverly you mess around with Javascript code the current (browser) implementations break all security. tptacek is a little "zealous" about this topic in particular :P (and I actually do see a use for JS crypto as a method of obfuscation, rather than security) but he is right.
    - tlrobinson 16y ago
      Of course desktop apps are usually downloaded from the web these days so they're also vulnerable to many of the same problems...
      - ErrantX 16y ago
        sorry, if it was not clear the problem is not with untrusted code. It is the ease with which code can be accessed and modified.
      - eli 16y ago
        Yeah, but you don't redownload them every time you run them.
  - count 16y ago
    I bet tptacek is wondering why he needs to keep saying the same thing over and over again :)
    - rubyrescue 16y ago
      if you are typing in the letters S-T-A-N-F-O-R-D while doing crypt... oh wait...
  - tptacek 16y ago
    It's a really good implementation built by really smart people who are making a calamitous mistake with how they market their work, because, like Colin Percival on Hacker News, they don't fully appreciate how badly generalist developers will abuse this code. "Oh boy!", they don't realize those developers will think, "now I don't have to buy an SSL certificate!".
    - michaelfairley 16y ago
      Was that jab at Colin really necessary?
      - tptacek 16y ago
        Presumably you were downmodded for suggesting that comparing Colin Percival to Dan Boneh is a "jab". I've modded you back up, but, now you know.
pierrefar 16y ago
Potentially, this could come in handy for app development frameworks like Appcelerator and Phonegap.
hackermom 16y ago
Problem: supporting only _one_ cipher (although at several key sizes). For those who are interested, there is also jsBFSH (Blowfish CBC), jsCrypto (AES, DES, 3DES), and, the JavaScript Crypto Library, which supports about 6 or 7 different ciphers at all common modus operandi, as well as several hash functions. jsBFSH - http://stolendata.net/~djinn/code/ http://stolendata.net/~djinn/code/ jsCrypto - http://sourceforge.net/projects/jscrypto/ http://sourceforge.net/projects/jscrypto/ JavaScript Crypto Library - http://etherhack.co.uk/main.html http://etherhack.co.uk/main.html
- briansmith 16y ago
  I consider that a feature, considering that cipher is AES. In fact, I would consider the AES-192 support superfluous. I wonder why they chose to support CCM instead of GCM.
  - tptacek 16y ago
    Because CCM is better documented and more popular than GCM, despite its (minor) flaws. If they wanted to look cool, they should have done EAX mode. Help me understand why people always make a point of sticking up for GCM. I've read the paper and I don't get what's so great about it. (For everyone else: ECB means "you can can cut-and-paste-and-shuffle blocks in the ciphertext", CBC means "you can't", CFB, OFB, and CTR mean "you can encrypt one byte at a time", and CCM, GCM, OCB, and EAX mean "you can encrypt one byte at a time and authenticate the message automatically so that it can't be tampered with".)
    - briansmith 16y ago
      AES-GCM is in NSA Suite B and AES-CCM and AES-EAX aren't. IIRC, EAX isn't even NIST approved. GCM is parallelizable, and CCM and EAX aren't. New Intel processors have special support for GCM, which should makes GCM notably faster. http://www.cryptopp.com/wiki/EAX_Mode http://www.cryptopp.com/wiki/EAX_Mode has a very brief but good summary of the advantages of GCM over CCM and EAX. Also see this slide (warning: PPT): http://www.cryptopp.com/w/images/c/ce/AtE-Comparison.ppt http://www.cryptopp.com/w/images/c/ce/AtE-Comparison.ppt
mr_justin 16y ago
Can somebody explain the practical, real-world use of a library like this? My first reaction was for encryption of sensitive data before a form post but then don't we have SSL for that? Plus, since it can be decrypted if you know the password, and the password is in the source code ... I don't understand why I would use this. Maybe for server-side JavaScript, such as node.js, but the authors of this plugin seem to omit server-side JavaScript from their notes for whatever reason.
- dagw 16y ago
  Off the top of my head, the one use a came up with would be to incorporate it into the web front end for a cloud based file storage site. This would give users a quick and painless way to encrypt files before uploading and offer protection against snooping employees.
  - hackermom 16y ago
    The only problem with string-only encryption, as used in Stanford's library, is that you have to base-encode your data first, costing extra time, and causing the data to grow in size (larger storage costs, more bandwidth usage). Using string-only keys is from a security perspective also a larger problem than people realize.
    - tptacek 16y ago
      Say what? SJCL uses full-width binary keys.
  - tptacek 16y ago
    This is a bad idea. The value of encrypting-before-uploading is that you don't have to trust the server. But you implicitly trust the server when you except encryption code for it. This fact usually sets off a day-long thread about the things you can do trust the code (read it! hash it! deliver it via SSL from a trusted CDN!), but these arguments always miss the fundamental point that you are trusting code that is (a) delivered over the network (b) at least partly by a server you don't trust (c) in an environment that binds arbitrary evals to every element of the DOM (d) using a language that allows you to override and booby-trap almost every operation. It's just not going to work. SJCL is awesome. Figuring out how to efficiently implement crypto in Javascript is a really valuable research project. But right now, you shouldn't be using this outside of serverside Javascript or custom clients. (And, really, if you have to type the letters A-E-S or H-M-A-C, you're doing it wrong anyways.)
superk 16y ago
The problem with clientside crypto (besides the security) is what do you do with it in the backend? Without matching code to decrypt on the backend it's pretty useless - unless you're using node, rhino or something. Porting javascript to another language is a pain because of the way javascript handles the long integers generated by these kinds of algorithms.
- nkassis 16y ago
  I think it's meant to be one way, encrypt the data and decrypt it when the server returns it to you. I don't see any other use for this.

70 points by siculars 16y ago

a1g 16y ago

nice I've been waiting for something like this. thank you.

tptacek 16y ago
Thank you in advance for putting my kids through college.

apike 16y ago

Sounds interesting. What does tptacek say?

siculars 16y ago
The main page does talk specifically about issues with running crypto in the browser: "Unforunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." Nevertheless, I wonder what tptacek thinks about the implementation.
- ErrantX 16y ago
  What it should probably say is: "Unforunately, this should not be considered a secure alternative to desktop applications because it is not feasible at all to protect against code injection, malicious servers and side-channel attacks." The unfortunate thing is that however cleverly you mess around with Javascript code the current (browser) implementations break all security. tptacek is a little "zealous" about this topic in particular :P (and I actually do see a use for JS crypto as a method of obfuscation, rather than security) but he is right.
  - tlrobinson 16y ago
    Of course desktop apps are usually downloaded from the web these days so they're also vulnerable to many of the same problems...
    - ErrantX 16y ago
      sorry, if it was not clear the problem is not with untrusted code. It is the ease with which code can be accessed and modified.
    - eli 16y ago
      Yeah, but you don't redownload them every time you run them.
- count 16y ago
  I bet tptacek is wondering why he needs to keep saying the same thing over and over again :)
  - rubyrescue 16y ago
    if you are typing in the letters S-T-A-N-F-O-R-D while doing crypt... oh wait...
- tptacek 16y ago
  It's a really good implementation built by really smart people who are making a calamitous mistake with how they market their work, because, like Colin Percival on Hacker News, they don't fully appreciate how badly generalist developers will abuse this code. "Oh boy!", they don't realize those developers will think, "now I don't have to buy an SSL certificate!".
  - michaelfairley 16y ago
    Was that jab at Colin really necessary?
    - tptacek 16y ago
      Presumably you were downmodded for suggesting that comparing Colin Percival to Dan Boneh is a "jab". I've modded you back up, but, now you know.

pierrefar 16y ago

Potentially, this could come in handy for app development frameworks like Appcelerator and Phonegap.

hackermom 16y ago

Problem: supporting only _one_ cipher (although at several key sizes). For those who are interested, there is also jsBFSH (Blowfish CBC), jsCrypto (AES, DES, 3DES), and, the JavaScript Crypto Library, which supports about 6 or 7 different ciphers at all common modus operandi, as well as several hash functions. jsBFSH - http://stolendata.net/~djinn/code/ http://stolendata.net/~djinn/code/ jsCrypto - http://sourceforge.net/projects/jscrypto/ http://sourceforge.net/projects/jscrypto/ JavaScript Crypto Library - http://etherhack.co.uk/main.html http://etherhack.co.uk/main.html

briansmith 16y ago
I consider that a feature, considering that cipher is AES. In fact, I would consider the AES-192 support superfluous. I wonder why they chose to support CCM instead of GCM.
- tptacek 16y ago
  Because CCM is better documented and more popular than GCM, despite its (minor) flaws. If they wanted to look cool, they should have done EAX mode. Help me understand why people always make a point of sticking up for GCM. I've read the paper and I don't get what's so great about it. (For everyone else: ECB means "you can can cut-and-paste-and-shuffle blocks in the ciphertext", CBC means "you can't", CFB, OFB, and CTR mean "you can encrypt one byte at a time", and CCM, GCM, OCB, and EAX mean "you can encrypt one byte at a time and authenticate the message automatically so that it can't be tampered with".)
  - briansmith 16y ago
    AES-GCM is in NSA Suite B and AES-CCM and AES-EAX aren't. IIRC, EAX isn't even NIST approved. GCM is parallelizable, and CCM and EAX aren't. New Intel processors have special support for GCM, which should makes GCM notably faster. http://www.cryptopp.com/wiki/EAX_Mode http://www.cryptopp.com/wiki/EAX_Mode has a very brief but good summary of the advantages of GCM over CCM and EAX. Also see this slide (warning: PPT): http://www.cryptopp.com/w/images/c/ce/AtE-Comparison.ppt http://www.cryptopp.com/w/images/c/ce/AtE-Comparison.ppt

mr_justin 16y ago

Can somebody explain the practical, real-world use of a library like this? My first reaction was for encryption of sensitive data before a form post but then don't we have SSL for that? Plus, since it can be decrypted if you know the password, and the password is in the source code ... I don't understand why I would use this. Maybe for server-side JavaScript, such as node.js, but the authors of this plugin seem to omit server-side JavaScript from their notes for whatever reason.

dagw 16y ago
Off the top of my head, the one use a came up with would be to incorporate it into the web front end for a cloud based file storage site. This would give users a quick and painless way to encrypt files before uploading and offer protection against snooping employees.
- hackermom 16y ago
  The only problem with string-only encryption, as used in Stanford's library, is that you have to base-encode your data first, costing extra time, and causing the data to grow in size (larger storage costs, more bandwidth usage). Using string-only keys is from a security perspective also a larger problem than people realize.
  - tptacek 16y ago
    Say what? SJCL uses full-width binary keys.
- tptacek 16y ago
  This is a bad idea. The value of encrypting-before-uploading is that you don't have to trust the server. But you implicitly trust the server when you except encryption code for it. This fact usually sets off a day-long thread about the things you can do trust the code (read it! hash it! deliver it via SSL from a trusted CDN!), but these arguments always miss the fundamental point that you are trusting code that is (a) delivered over the network (b) at least partly by a server you don't trust (c) in an environment that binds arbitrary evals to every element of the DOM (d) using a language that allows you to override and booby-trap almost every operation. It's just not going to work. SJCL is awesome. Figuring out how to efficiently implement crypto in Javascript is a really valuable research project. But right now, you shouldn't be using this outside of serverside Javascript or custom clients. (And, really, if you have to type the letters A-E-S or H-M-A-C, you're doing it wrong anyways.)

superk 16y ago

The problem with clientside crypto (besides the security) is what do you do with it in the backend? Without matching code to decrypt on the backend it's pretty useless - unless you're using node, rhino or something. Porting javascript to another language is a pain because of the way javascript handles the long integers generated by these kinds of algorithms.

nkassis 16y ago
I think it's meant to be one way, encrypt the data and decrypt it when the server returns it to you. I don't see any other use for this.