Stanford's Javascript Crypto Library | Hacker News Reader

Stanford's Javascript Crypto Library

bitwiseshiftleft.github.com

70 pointssiculars42 comments

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.

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.

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.

Say what? SJCL uses full-width binary keys.

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

node.js has OpenSSL bindings.

It could be useful in extensions for browsers which support javascript-based plugins, like Firefox and Chrome.

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

Sounds interesting. What does tptacek say?

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.

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.

Of course desktop apps are usually downloaded from the web these days so they're also vulnerable to many of the same problems...

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.

Yeah, but you don't redownload them every time you run them.

I bet tptacek is wondering why he needs to keep saying the same thing over and over again :)

if you are typing in the letters S-T-A-N-F-O-R-D while doing crypt... oh wait...

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!".

Was that jab at Colin really necessary?

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.

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.

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.

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

Thank you in advance for putting my kids through college.

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/

jsCrypto - http://sourceforge.net/projects/jscrypto/

JavaScript Crypto Library - http://etherhack.co.uk/main.html

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.

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".)

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

And there's my answer. Thanks!

I think one of the main reasons for that is to make it simpler to use. The API is so simple it almost looks like the api to a cache

jsBFSH is even thinner :) Very "bare bone" and compact lib, though it doesn't work with strings at all, only arrays, most likely to facilitate use on binary data and to support binary keys instead of just textual ones.

Explain to the audience why anyone would ever choose to encrypt something with Blowfish in a new application. I'd ask you to justify using DES or 3DES, but, you can't.

Explain to us instead what security concerns there are with the cipher. As you mention DES and 3DES, known to be very vulnerable today, you are implying that you know of security issues with the Blowfish cipher, so, please enlighten us - what is that all of the cryptographers in the world except you have completely missed regarding cryptanalysis and weaknesses of this cipher?

Please don't bring any performance claims up, because if you are really as familiar with Blowfish as you appear to imply, then you know very well that with a proper implementation (and there as many bad ones as good ones) it outperforms all of the AES ciphers by several times. Also don't bring up the "incredibly slow" key schedule as a valid point of "why no one should ever use it", because it's not really slow, even by yesterday's measures of computational power.

add.: I'll give you a few reasons of why the cipher is still interesting just for the sake of the discussion :)

1) same encryption time regardless key size - 448 bits of key perform just as fast as 8 bits.

2) very sophisticated s-box/key schedule - trying to brute force the cipher is practically impossible as the raw key is not used in the encryption/decryption process itself, and performing the s-box setup for every bit of possible key pushes the brute force process back a few orders of magnitude in speed, and, trying to brute force by traversing the p- and s-boxes, all 8768 bits worth, just ain't happening today.... or tomorrow.

3) performance - among the (so far) unbroken ciphers, it's quite possibly the fastest one.

Here's one that's easy to understand: it shares with DES and 3DES an 8-byte block size, which makes a bunch of integrity exploits easier to write. Schneier, who has all but disavowed Blowfish, would also point out that a 64 bit block size gives you a little less than 2^32 block encryptions under the same key before you run into statistical hazards, but I don't care about that.

The block size / integrity issue is a pragmatic complaint, but the real issue here is: why on earth would you use Blowfish instead of AES when AES has received many multiples as much scrutiny as Blowfish?

Regarding Twofish, the successor to Blowfish, Schneier writes in _Practical_:

That [~10 grafs preceding] does not leave a lot of room for Twofish. You should only choose Twofish [again, Twofish, not the obsoleted Blowfish] if you want the speed of AES without the security disadvantages listed above. Of course, all the institutional advantages of AES will now weigh against you. If Twofish is ever broken, you will be blamed for selecting it.

I think you can probably tell that the reason I commented about using anything but AES has less to do with the specifics of Blowfish --- which, again, are unfavorable --- and more to do with the concept of selecting libraries solely for the purpose of writing vanity crypto. Cryptosystems that use Blowfish are vanity systems.

Let's be very clear that I could give a fuck how fast a cipher is. Smarter people than me who have spent more of their lives on this problem have optimized the universe of acceptable ciphers for speed already. That universe does not include Blowfish (or, for that matter, Twofish --- although who knows, that could eventually change).

I really can't see any compelling point here of why Blowfish should be avoided when the case is that its benefits panders well towards the intended means, just because there are obvious risks involved - as with all ciphers. These risks you point out exist today in one flavor or the other for AES as well; exploits loom around them, too (and to be fair, AES, too, has its fair share of dangers that Blowfish is immune to), but you seem inclined to ignore AES' case seemingly only because of its young age. Mind you, Blowfish has had its share of prying eyes, too, but I don't think that the amount of scrutiny involved in these two ciphers weighs particularly much at this point when both ciphers are still unbroken. What you're laying forth in AES' favor is really the exact same tune people sang in favor of DES 20 years ago. I find it ironic that, given Blowfish's strengths, you pass all of its use in modern software off as plain, simple vanity. Is OpenBSD's use of Blowfish vain in any way what so ever? Is interest in, or a requirement of, high performance or a compact codebase vanity?

And, just to end your weird assumption, let's also be clear that I threw out examples of cryptography libraries for the surplus value of having additional choices at hand, not in any was as passing out advices on what ciphers to use for what purpose. I don't like when people imply that I'm an indoctrinating zealot.

(a) Yes, OpenBSD's use of Blowfish was a vanity move (outside of bcrypt, which takes special advantage of a Blowfish quirk in a setting where Blowfish's other disadvantages aren't relevant). But it's also an understandable one, since OpenBSD's adoption of Blowfish predates even Rijndael.

(b) The risks of using a cipher with a 64 bit block size are simple and pragmatic, and there's almost certainly no offsetting advantages.

(c) I don't understand any of the rest of your arguments. I don't think you're an "indoctrinating zealot" (at least, I don't think I think that; I don't know what you mean.)

(d) Choice in cryptography is bad. This is not a 'tptacek idiosyncracy. Ferguson and Schneier's book has essentially that principal as its thesis. So do the modern crypto libraries.

You seem to have some background with this material. Can you tell me about a system you've implemented that used Blowfish, or any selectable or negotiated block cipher? I'm curious (and have a follow-up question).

Some years ago I wrote custom software for voice/memo and messaging (incl. storage) for a cellphone-based intercom system used in one or more of PricewaterhouseCoopers' establishments here in Sweden. Their offices residing in public complexes prompted the concern for privacy, and they wanted a communications system of their own rather than relying on GSM intercom or buying in on other solutions available at large on the market. I chose Blowfish because I knew I could make it run faster (read: lower power consumption) than AES or any other applicable cipher, which was a priority for their handheld devices, and because I knew that it wasn't at risk of being broken.

What cipher mode did you use, how did you establish keys, what parts of messages were encrypted vs. not encrypted (control channel, call setup, keepalives, audio frames, etc), and how did you protect integrity?

(That's my followup question).

I didn't write any protocols, didn't design any schemes in the chain of communication; the "engineers" sourced different people for different parts for obvious reasons. I wrote the ADPCM codec for the audio and the bare crypto component. My implementation allowed both EBC and CBC modes. I know keys were randomized for each handheld by the exchange every time an employee checked out a handheld.

So basically, and excuse the snark here because I really don't think you're dumb or anything, but... you have a lot of very strong opinions about whether developers should be able to use a 17-year old 64-bit block cipher, but not a lot of opinions about anything that goes into making a block cipher construction secure.

(Why did you allow ECB to be used?)

I think you're (again) falsely assuming something here. I definitely have opinions about what modes of operation should be used for a cipher, as it's yet another sensitive link in the chain. ECB operation was added because the head above me requested it to be there, not from my design choice.

I think your fervent and, with all respect to your undebatable knowledge in this topic, priggish nature makes you prone to turn discussions into "unstoppable force meets immovable object" farces, if you understand what I mean, so let's just agree on disagreeing about ciphers :)

Sorry, but I wouldn't have lasted very long in this field if "fear of sounding priggish" had a major impact on my behavior, so let me give this to you straight:

In response to SJCL, a library implemented by bona fide cryptographers that at least attempts to capture some of the pitfalls of doing crypto code, you, because of the fact that the library doesn't offer the obsolete Blowfish cipher, recommended:

* A Blowfish library that implements only the terribly insecure ECB block cipher mode, which you wouldn't know unless you looked at the code since it doesn't call it "ECB"

* A library that claims to implement CBC mode but in fact implements ECB mode, and, as an added bonus, implements RSA as nothing but a wrapper around bignum math.

* A library that implements CBC mode --- though without control over IVs --- but only for AES; Blowfish is stuck in ECB mode. Recall your reason for citing the library was "access to things like Blowfish".

I'm sorry, but you just gave really bad advice. Give better advice and I promise I'll be less of a twat. I am, for the record, not a crypto expert. Colin Percival is our resident crypto expert. All I know is what I know. In this case, that includes: don't do what 'hackermom just said to do.

stumbled over this via the referrer list on my host and thought i'd just add something for the record: my jsbfsh does cbc only, not ecb. i think the one making guesses instead of looking at code was you ;-) this was a very interesting and complementing discussion thread.

Reply on news.ycombinator.com