Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Parent Full thread

As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year.

I read his comments as being "there is nothing good; here's why all of these things suck, but I grudgingly guess Keyczar works for some people". The only alternatives under discussion are cryptlib, which only has C bindings currently, and djb's new thing which uses brand new (well, four year old) ciphers that nobody other than djb really understands or knows to be secure. Given that Keyczar has some major corporate backing, and a reasonable level of community support, it seems a pretty solid choice...despite its imperfections. djb's thing might be an awesome choice...but we don't know and I'm definitely not qualified to figure it out.

Again, I'm just some guy, you know? I don't understand the nuances of security very well, but I read what I can and try to make some sense out of the kinds of answers security experts provide (which, for some reason, always seem to be qualified into being no-op statements; I guess because committing to recommending something means you can be proven wrong later when that recommendation proves insecure).

So, my reading comprehension I guess is as weak as my crypto knowledge, since I came away thinking, "Well, there's nothing good to use. But maybe Keyczar or cryptlib is better than what we're doing now; djb's might be awesome in the future. cryptlib has an annoying deployment aspect and would require me to write bindings that would probably be insecure, so Keyczar seems maybe the best of a bad lot."

I don't know of anyone who has a problem with Guttman's cryptlib. If I had to choose between NaCl and Keyczar right now, I'd recommend (after "not doing crypto") using NaCl.

I think that it's unlikely that you'll introduce serious crypto flaws by writing a binding to a high-level interface (the same is not true of binding to low-level interfaces like OpenSSL, where you could very easily weaken a construction).

cryptlib has many HLL bindings. If you're building something that's compatible with its Sleepycat license (GPL if you're OSS, pay if you're not), then just use it.

djb's little creation needs more cooking, that much is for certain. Brand new all but unreviewed ECDH, stream and hash functions. The hash isn't even in the SHA-2 competition. It doesn't matter who djb thinks he is, using this library in its current form is irresponsible.

Salsa20 is an ECRYPT eSTREAM Phase 4 cipher, tied with Rabbit for the #1 software stream cipher. eSTREAM is to stream ciphers what what the AES competition was to block ciphers. The eSTREAM committee included Bart Preneel, Vincent Rijmen, and Matt Robshaw. If the thing you're reacting to is that NaCl doesn't use AES, note that the peer review Salsa20 got was substantial.

Elliptic Curve Diffie-Hellman (ECDH) isn't "all but unreviewed". ECDH is a NIST standard. Curve25519 is just an implementation of ECDH over a set of parameters that admits to especially fast implementation.

The hash function in NaCl is SHA-512.

Poly1305 isn't a hash function. It's a polynomial MAC, similar to what's used in the NIST standard GCM. If that's what you were referring to as "the hash function that isn't even in the SHA-2 competition", note that none of the NIST authenticated encryption modes use (comparatively slow) generic hash function constructions like HMAC, and none of the MAC functions they do use (OMAC, CBC-MAC, GCM's poly eval) have been entered, like apples, into SHA-2's orange competition.

I don't know who you think Daniel J. Bernstein is, but the short answer is: extremely reputable cryptographic researcher.

The sad thing is, your core argument --- that it would be "safer" to use NaCl using the NIST curves and AES --- is valid, and would have been informative if you hadn't chosen to phrase it in such a dismissive way. As it stands, I'm left thinking you don't know what you're talking about and just stumbled on this critique, particularly as your professional background contains basically no crypto or security.

Either way, you are almost certainly better off using NaCl with DJB's bespoke algorithms than you are trying to patch AES, HMAC-256, and RSA together using OpenSSL. We break actual peer-reviewed cryptographic algorithms in the field during penetration tests basically never. We break homebrew AES and RSA constructions about once a month.

What I was trying to get across in my post is that there is no easy answer currently. cryptlib may be best if you are ok with the license. Keyczar is a good start, but it needs more time to be fully-baked. GPGME is a bit clunky and C-only. I have no clear recommendation, and that sucks.

Hopefully people will rally around these. Cryptographers to review these libraries and NaCl. Developers to add the HLL bindings. Note that NaCl has a high-level API, so the HLL binding may just be SWIG + wrapper to convert length-counted byte buffers into the appropriate sequence type.

I think "irresponsible" is much too strong. As tptacek says, he is getting a lot of review and his constructions are not excessively risky. I just think they need more time to be reviewed and the early findings seem to be that they are pretty good.

Reply on news.ycombinator.com