
Stanford JavaScript Crypto Library - memexy
http://bitwiseshiftleft.github.io/sjcl/
======
buu700
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.

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

~~~
Thorrez
How does it compare to [https://tweetnacl.js.org](https://tweetnacl.js.org) ?
That's 7KB minified and gzipped.

~~~
buu700
TweetNaCl.js is great. I'd go with that if you really need something smaller
than libsodium.

Presumably it shares the downsides of TweetNaCl ("doesn't wipe internal
buffers [...] [and] has two harmless instances of undefined behaviour"[1];
among, I expect, other shortcuts that may make it less optimal/safe than
NaCl), and the fact that it's pure JS adds additional side channel attack
surface, but those may be acceptable risks depending on your threat model.
They're certainly the least of your concerns if you're just using it in a web
page like 0bin.net.

1: [https://monocypher.org/why](https://monocypher.org/why)

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

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

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

------
johnisgood
[https://www.nccgroup.com/us/about-us/newsroom-and-
events/blo...](https://www.nccgroup.com/us/about-us/newsroom-and-
events/blog/2011/august/javascript-cryptography-considered-harmful/)

How relevant is it today?

------
dchest
Don’t use it, just use WebCrypto API.

~~~
BiteCode_dev
It's way lower level, and easier to missuse.

~~~
henriquez
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/SubtleCrypt...](https://developer.mozilla.org/en-
US/docs/Web/API/SubtleCrypto)

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.

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

That's a really nice feature. This should be better advertised. I wasn't aware
that Web Crypto was even a thing.

~~~
codysc
Yes, that kinda HSMish model of non-extractable keys is a very nice touch. I
really wish they would add Argon2 though. PBKDF2 is still a valid choice but
there are a lot of HW optimized solvers out there for it.

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

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

~~~
BiteCode_dev
Size

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

