6 ms·

Stanford JavaScript Crypto Library

78 points by memexy 6y ago

memexy 6y ago
Found it while looking at TiddlyWiki developer documentation. This is used to make encrypted wiki pages that are decrypted on the client.
buu700 6y ago
I would personally recommend libsodium.js as the default choice for a JS crypto library: https://github.com/jedisct1/libsodium.js https://github.com/jedisct1/libsodium.js Fundamental issues with JS/web crypto aside, that is. You would still need something like WebSign (https://www.cyph.com/websign https://www.cyph.com/websign) or a framework like Electron that allows shipping your application outside of the browser.
- traceroute66 6y ago
  Agree on the libsodium recommendation. Stanford probably just suffering a little "not invented here" syndrome. Libsodium is a solid crypto library with long history. It is also embedded in PHP,HHVM,Citrine and Factor "out of the box" and has bindings for many other languages, not just Javascript. In my view, any competing crypto library would have to be something super special to outweigh all the pros of libsodium.
  - hackernewsn00b 6y ago
    > Stanford probably just suffering a little "not invented here" syndrome. SJCL predates libsodium.js :)
    - thephyber 6y ago
      This appears so. From the SJCL documentation: > An older version of this implementation is available in the public domain, but this one is (c) Emily Stark, Mike Hamburg, Dan Boneh, Stanford University 2008-2010 and BSD-licensed for liability reasons.
  - jonas21 6y ago
    > any competing crypto library would have to be something super special to outweigh all the pros of libsodium. Like interoperating with anything not designed by djb?
- deleted 6y ago
  [deleted]
- BiteCode_dev 6y ago
  SJCL is 6.4KB gzipped, libsodium is 188KB. If one plans to use the lib in the browser, it makes a huge difference. Also, I'm not a crypto expert by any mean, but SJCL seems higher level, and hence, easier to use. Not to mention harder to missuse. Projects like https://0bin.net https://0bin.net have been using it for 7 years, with 500000 visitors in the last few months, so I'd say it's pretty battle tested too. Not nearly has much as libsodium, of course. But I wouldn't discard SJCL, I think it has a place.
  - buu700 6y ago
    That's a fair point, to some extent. If you're specifically looking to perform symmetric encryption on a string with a string-encoded password, then yes, SJCL is easier to use. The documentation is centered around that one simple example, and the library doesn't seem to do a lot else (at least through a high-level API). I also have a problem with NaCl/Sodium forcing users to handle nonces, rather than handling that detail internally by default. Besides that, Sodium isn't particularly more difficult to use than SJCL; the whole point is that it's an easy-to-use high-level interface that's hard to misuse. I would also note that SJCL's defaults are a bit dated (CCM vs GCM, 128-bit vs 256-bit, PBKDF2 vs a memory-hard KDF like scrypt or Argon2). Additionally, being pure JS would raise concerns about side channel attacks more so than WebAssembly (like libsodium.js) or native code (like WebCrypto). I'm sure there are simple use cases where SJCL provides some value, and I'm not saying data and applications that depend on it out in the wild should necessarily be considered already compromised, but I'd struggle to think of a situation where I would consider using it in a new project today, over either libsodium or nothing at all / just TLS.
  - Thorrez 6y ago
    How does it compare to https://tweetnacl.js.org https://tweetnacl.js.org ? That's 7KB minified and gzipped.
    - BiteCode_dev 6y ago
      Never tried it
    - 6y ago
- arvinsim 6y ago
  Hmm I am currently testing out node-forge for encrypting/decrypting AES-256. Would you say that libsodium.js is better?
  - buu700 6y ago
    I would go with libsodium.js (which binds to the native C library in Node.js) if you just need to encrypt/decrypt in general, especially if you anticipate building out other cryptographic features in the future. If you need AES in particular, node-forge is probably fine, although from a quick glance it looks almost identical to Node's built-in crypto API, in which case you could just use that, but they both look pretty inconvenient (excessively low-level) to use directly.
  - technion 6y ago
    I haven't used this, so I went and read the documentation. node-forge is a good example of giving a user too many options in my view. As a developer looking to secure something, you've apparently decided on AES-256 against options like "DES" and "RC2" that are on offer. That's a good step. Now you get to choose between ECB, CBC, CFB, OFB, CTR. Which is a good idea? Which isn't? The documentation appears to just say "here is a great example of using CBC mode". That example is vulnerable to a padding oracle (uses PKCS#7 and has no form of MAC). From what I'm reading it's left as an exercise to the reader to record the iv somewhere. If you did want a hash, it helpfully suggests MD5 as reasonable. This isn't a great example of crypto engineering.
dchest 6y ago
Don’t use it, just use WebCrypto API.
- BiteCode_dev 6y ago
  It's way lower level, and easier to missuse.
  - henriquez 6y ago
    The only low-level thing I noticed about the native Web Crypto APIs is its reliance on typed arrays. The speed difference is night and day as the native stuff can be hardware-accelerated by dedicated CPU instructions. Browser support is very good: https://caniuse.com/#feat=cryptography https://caniuse.com/#feat=cryptography Documentation is also very good: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... In terms of "ease of misuse" it's debatable. One of the biggest default security improvements with Web Crypto is that *cryption keys are _not readable by JS_ once instantiated - they can only be used by the cryptographic functions (unless you explicitly make them exportable). This is a subtle but very important defense against certain drive-by attacks that could dump loaded keys from whatever non-native JS crypto library you might be using. In general I don't think it's safe to be using crypto at all outside of basic stuff like password hashing if you don't have a basic understanding of concepts like salt lengths, block cipher modes, hasher output sizes, etc. so I don't really agree with the "easier to misuse" statement. Some library that holds your hand more isn't going to significantly make things safer.
    - codysc 6y ago
      I agree that Web Crypto has a lot to offer. I use it in my latest project. In terms of it being easy to misuse, I think that applies to cryptography in general, but there are some gotchas lingering in javascript. Self blog promoting. I just put this out a few days ago on this very subject. https://pritact.com/blog/posts/crypto-mistakes-part-1.html https://pritact.com/blog/posts/crypto-mistakes-part-1.html
    - 6y ago
carterklein13 6y ago
Does this add anything that many of the more popular and widely-used crypto libraries offer? I haven't been able to find anything, but am always curious to try new tools.
- avmich 6y ago
  What would those many libraries offer, deserving switching from SJCL? I particularly like the size of the library; having said that, there could be some more important features.
kyledrake 6y ago
Having used SJCL before, I'll just say that it's quite old, and I'm not sure how well maintained it is at this point. It also is likely not using any of the new crypto browser APIs which can speed things up like pbkdf2 a ton. Recommend using something more modern and "on the rails" like libsodium if you have a choice.
mikece 6y ago
Why not just a C or C++ crypto library compiled to WASM?
- BiteCode_dev 6y ago
  Size
  - mikece 6y ago
    How much? One of the crypto libraries cited in the comments is about 10x the size of SJSC. Besides, as an avid use of Signal, Wire, Bitwarden, and other e2e encrypted tools, I would GLADLY download a larger but superior encryption tool that is compiled to WASM instead of relying on JS.
johnisgood 6y ago
https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.com/us/about-us/newsroom-and-events/blo... How relevant is it today?
hasa 6y ago
I'm thinking this from the security point of view. Unless you bring the crypto operations outside the battlefield of JS runtime, any js library is basically unsecure.

78 points by memexy 6y ago

Found it while looking at TiddlyWiki developer documentation. This is used to make encrypted wiki pages that are decrypted on the client.

buu700 6y ago

I would personally recommend libsodium.js as the default choice for a JS crypto library: https://github.com/jedisct1/libsodium.js https://github.com/jedisct1/libsodium.js Fundamental issues with JS/web crypto aside, that is. You would still need something like WebSign (https://www.cyph.com/websign https://www.cyph.com/websign) or a framework like Electron that allows shipping your application outside of the browser.

traceroute66 6y ago
Agree on the libsodium recommendation. Stanford probably just suffering a little "not invented here" syndrome. Libsodium is a solid crypto library with long history. It is also embedded in PHP,HHVM,Citrine and Factor "out of the box" and has bindings for many other languages, not just Javascript. In my view, any competing crypto library would have to be something super special to outweigh all the pros of libsodium.
- hackernewsn00b 6y ago
  > Stanford probably just suffering a little "not invented here" syndrome. SJCL predates libsodium.js :)
  - thephyber 6y ago
    This appears so. From the SJCL documentation: > An older version of this implementation is available in the public domain, but this one is (c) Emily Stark, Mike Hamburg, Dan Boneh, Stanford University 2008-2010 and BSD-licensed for liability reasons.
- jonas21 6y ago
  > any competing crypto library would have to be something super special to outweigh all the pros of libsodium. Like interoperating with anything not designed by djb?
deleted 6y ago
[deleted]
BiteCode_dev 6y ago
SJCL is 6.4KB gzipped, libsodium is 188KB. If one plans to use the lib in the browser, it makes a huge difference. Also, I'm not a crypto expert by any mean, but SJCL seems higher level, and hence, easier to use. Not to mention harder to missuse. Projects like https://0bin.net https://0bin.net have been using it for 7 years, with 500000 visitors in the last few months, so I'd say it's pretty battle tested too. Not nearly has much as libsodium, of course. But I wouldn't discard SJCL, I think it has a place.
- buu700 6y ago
  That's a fair point, to some extent. If you're specifically looking to perform symmetric encryption on a string with a string-encoded password, then yes, SJCL is easier to use. The documentation is centered around that one simple example, and the library doesn't seem to do a lot else (at least through a high-level API). I also have a problem with NaCl/Sodium forcing users to handle nonces, rather than handling that detail internally by default. Besides that, Sodium isn't particularly more difficult to use than SJCL; the whole point is that it's an easy-to-use high-level interface that's hard to misuse. I would also note that SJCL's defaults are a bit dated (CCM vs GCM, 128-bit vs 256-bit, PBKDF2 vs a memory-hard KDF like scrypt or Argon2). Additionally, being pure JS would raise concerns about side channel attacks more so than WebAssembly (like libsodium.js) or native code (like WebCrypto). I'm sure there are simple use cases where SJCL provides some value, and I'm not saying data and applications that depend on it out in the wild should necessarily be considered already compromised, but I'd struggle to think of a situation where I would consider using it in a new project today, over either libsodium or nothing at all / just TLS.
- Thorrez 6y ago
  How does it compare to https://tweetnacl.js.org https://tweetnacl.js.org ? That's 7KB minified and gzipped.
  - BiteCode_dev 6y ago
    Never tried it
  - 6y ago
arvinsim 6y ago
Hmm I am currently testing out node-forge for encrypting/decrypting AES-256. Would you say that libsodium.js is better?
- buu700 6y ago
  I would go with libsodium.js (which binds to the native C library in Node.js) if you just need to encrypt/decrypt in general, especially if you anticipate building out other cryptographic features in the future. If you need AES in particular, node-forge is probably fine, although from a quick glance it looks almost identical to Node's built-in crypto API, in which case you could just use that, but they both look pretty inconvenient (excessively low-level) to use directly.
- technion 6y ago
  I haven't used this, so I went and read the documentation. node-forge is a good example of giving a user too many options in my view. As a developer looking to secure something, you've apparently decided on AES-256 against options like "DES" and "RC2" that are on offer. That's a good step. Now you get to choose between ECB, CBC, CFB, OFB, CTR. Which is a good idea? Which isn't? The documentation appears to just say "here is a great example of using CBC mode". That example is vulnerable to a padding oracle (uses PKCS#7 and has no form of MAC). From what I'm reading it's left as an exercise to the reader to record the iv somewhere. If you did want a hash, it helpfully suggests MD5 as reasonable. This isn't a great example of crypto engineering.

dchest 6y ago

Don’t use it, just use WebCrypto API.

BiteCode_dev 6y ago
It's way lower level, and easier to missuse.
- henriquez 6y ago
  The only low-level thing I noticed about the native Web Crypto APIs is its reliance on typed arrays. The speed difference is night and day as the native stuff can be hardware-accelerated by dedicated CPU instructions. Browser support is very good: https://caniuse.com/#feat=cryptography https://caniuse.com/#feat=cryptography Documentation is also very good: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... In terms of "ease of misuse" it's debatable. One of the biggest default security improvements with Web Crypto is that *cryption keys are _not readable by JS_ once instantiated - they can only be used by the cryptographic functions (unless you explicitly make them exportable). This is a subtle but very important defense against certain drive-by attacks that could dump loaded keys from whatever non-native JS crypto library you might be using. In general I don't think it's safe to be using crypto at all outside of basic stuff like password hashing if you don't have a basic understanding of concepts like salt lengths, block cipher modes, hasher output sizes, etc. so I don't really agree with the "easier to misuse" statement. Some library that holds your hand more isn't going to significantly make things safer.
  - codysc 6y ago
    I agree that Web Crypto has a lot to offer. I use it in my latest project. In terms of it being easy to misuse, I think that applies to cryptography in general, but there are some gotchas lingering in javascript. Self blog promoting. I just put this out a few days ago on this very subject. https://pritact.com/blog/posts/crypto-mistakes-part-1.html https://pritact.com/blog/posts/crypto-mistakes-part-1.html
  - 6y ago

carterklein13 6y ago

Does this add anything that many of the more popular and widely-used crypto libraries offer? I haven't been able to find anything, but am always curious to try new tools.

avmich 6y ago
What would those many libraries offer, deserving switching from SJCL? I particularly like the size of the library; having said that, there could be some more important features.

kyledrake 6y ago

Having used SJCL before, I'll just say that it's quite old, and I'm not sure how well maintained it is at this point. It also is likely not using any of the new crypto browser APIs which can speed things up like pbkdf2 a ton. Recommend using something more modern and "on the rails" like libsodium if you have a choice.

mikece 6y ago

Why not just a C or C++ crypto library compiled to WASM?

BiteCode_dev 6y ago
Size
- mikece 6y ago
  How much? One of the crypto libraries cited in the comments is about 10x the size of SJSC. Besides, as an avid use of Signal, Wire, Bitwarden, and other e2e encrypted tools, I would GLADLY download a larger but superior encryption tool that is compiled to WASM instead of relying on JS.

johnisgood 6y ago

https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.com/us/about-us/newsroom-and-events/blo... How relevant is it today?

hasa 6y ago

I'm thinking this from the security point of view. Unless you bring the crypto operations outside the battlefield of JS runtime, any js library is basically unsecure.