5 ms·
Problem: supporting only _one_ cipher (although at several key sizes). For those who are interested, there is also jsBFSH (Blowfish CBC), jsCrypto (AES, DES, 3
by hackermom 16y ago
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/ http://stolendata.net/~djinn/code/
jsCrypto - http://sourceforge.net/projects/jscrypto/ http://sourceforge.net/projects/jscrypto/
JavaScript Crypto Library - http://etherhack.co.uk/main.html http://etherhack.co.uk/main.html
- briansmith 16y agoI 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.
- tptacek 16y agoBecause 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".)
- briansmith 16y agoAES-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 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 http://www.cryptopp.com/w/images/c/ce/AtE-Comparison.ppt
- tptacek 16y agoAnd there's my answer. Thanks!
- jiaaro 16y agoI 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
- hackermom 16y agojsBFSH 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.
- tptacek 16y agoExplain 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.
- deleted 16y ago[deleted]
- hackermom 16y agoExplain 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 16y agoHere'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).