

Stanford's Javascript Crypto Library - siculars
http://bitwiseshiftleft.github.com/sjcl/

======
mr_justin
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
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
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
Say what? SJCL uses full-width binary keys.

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

------
apike
Sounds interesting. What does tptacek say?

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

~~~
tptacek
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
Was that jab at Colin really necessary?

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

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

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

~~~
tptacek
Thank you in advance for putting my kids through college.

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

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

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

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

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

~~~
tptacek
(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).

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

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

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

~~~
tptacek
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?)

~~~
hackermom
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 :)

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

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

