libsodium.js

I would personally recommend libsodium.js as the default choice for a JS crypto library: 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) or a framework like Electron that allows shipping your application outside of the browser.

We looked at libsodium and its choices impacted our discussions on our system. We decided not to use it because it's not compatible with many browsers [0] We also discussed using a modern asymmetric key algorithm. We decided on Diffie-Hellman because we were extremely confident it's secure (so long as we choose the right parameters and implement it correctly), and would be very simple to fit it into our architecture. [0] https://github.com/jedisct1/libsodium.js/#compatibility

I had to do a little digging into where it was pulling its crypto methods from and it looks like the have a bit of their own library, but it uses libsodium via javascript wrappers underneath: https://github.com/TankerHQ/sdk-js/tree/master/packages/cryp... https://github.com/jedisct1/libsodium.js So, I guess take that as you will. I haven't read much of the actual source yet. edit: I sort of expected there would be a move to the server since it looks like they built their library to run on the server, even if it's running all of the libsodium methods in javascript but it's definitely pulling the browser version and running it all in the client: https://github.com/TankerHQ/sdk-js/blob/master/packages/file...

libsodium is written in c. "Pure javascript" is a supported compilation target[0] of the project. Emscripten is used to compile the c to javascript. There's also now a wasm compilation target, again via emscripten. The c source code is really excellent[1]. It's worth browsing! [0]-https://github.com/jedisct1/libsodium.js [1]-https://github.com/jedisct1/libsodium/tree/master/src/libsod...

That's a fun toy.. and a great example of how easy it is to get crypto wrong. I'm just guessing here, but you are probably missing some key derivation like PBKDF2. Edit: For this something like tweetnacl is probably more foolproof, checkout: https://github.com/dchest/tweetnacl-js Or libsodium which can also be compiled to pure js: https://github.com/jedisct1/libsodium.js

How does this compare to libsodium(.js)[1][2]? [1] https://github.com/jedisct1/libsodium [2] https://github.com/jedisct1/libsodium.js

Yes, kind of. I use SJCL in Turtl (https://turtlapp.com) which is packaged as standalone browser app (nwjs on desktop, xwalk on android). I'd never publish the app as a web app (at least not without significant warnings to the user/an opt-in) but technically yes, we use client-side crypto in a browser. SJCL is kind of a pain in the ass though, to be honest. It was built before Uint8Array was prevalent, meaning all your crypto data has to be encoded as a string, and you have to be extra cautious of UTF8 data (you have to decode/encode your data as ASCII strings). Someone please correct me if this is no longer the case. Recently I've been playing with the emscripten port of libsodium (https://github.com/jedisct1/libsodium.js), which seems to be working quite well. I have yet to benchmark, but the nice thing is that eventually I can replace

Scrypt for key derivation, chacha20+poly1305 for authenticated secret-key encryption. In Javascript, https://github.com/jedisct1/libsodium.js provides them.

I noticed the inclusion of NIST curves and no modern ECC and decided I'd withhold judgment until someone else had a chance to look at it. This is pretty terrible. If anyone was looking forward to using this for creating browser extensions (do NOT deliver code from a webserver and assume it's safe!), you're better off using https://github.com/jedisct1/libsodium.js instead.