Hacker News Reader

Comment by cperciva | Hacker News Reader

    You should come to my conference talk, "everything
    you need to know about crypto in 1 hour". :-)

Boy, I wish something like that existed

It does! I'm giving that talk at BSDCan'10 in May: http://news.ycombinator.com/item?id=1179569

View on HN

Is the content going to be much different than your "Cryptographic right answers" post?: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

My talk is basically an expansion of that blog post.

It would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?

RSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up".

AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?

The arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it.

The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet.

Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about.

Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.

There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself.

The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SHA256 or evaluate-a-polynomial-over-a-finite-field-then-AES-encrypt. The latter is possible to do in constant time, but takes some work; the former is almost impossible to do not in constant time. As for performance, I haven't done any tests, but just given the bit-complexity of finite field multiplication, I'm sure HMAC-SHA256 is much faster.

For the record, I would never recommend AES-CBC-SHA. That's an absolutely horrible construction which nobody should ever use.

Well, mobile phones are a huge market for this stuff right now. I've found that regular DHE adds latency perceivable by the end user in my mobile apps, because they have to wait for the (fast but heavily-loaded) server to calculate the modular exponentiation, and then they have to wait for their slow phone's processor to calculate the modular exponentiation.

When I said AES-CBC-SHA, I meant AES-CBC-HMAC-SHA. The TLS ciphersuites are named without explicitly saying "HMAC"; e.g. TLS_RSA_WITH_AES_128_CBC_SHA is RSA key exchange with AES-128 in CBC mode as the bulk cipher, authenticated with HMAC-SHA1.

The practical problem that people will have with your advice is that they will want to implement it using TLS (despite your recommendation not to use SSL), and TLS doesn't have any standard AES-CTR-[HMAC-]SHA256 cipher suites; there's only standards for AES-CBC-[HMAC-]SHA, AES-GCM, and AES-CCM.

Yes, I assumed you meant AES-CBC-HMAC-SHA. But CBC mode is horrible, and nobody should use SHA any more.

And I agree that out of AES-CBC-SHA, AES-GCM, and AES-CCM, the best choice is AES-GCM. But my advice was primarily directed towards people not using TLS.

Nice - I thought you were being sarcastic!

I don't know if I can make it in person, but I sure hope they tape it and put it online :-D

If nothing else, I'll put my slides online -- but coming in person would give you the opportunity to hear me speak and ask questions at the talk, too.

Sweet. I'll be looking forward to the slides, or if there's a video of the talk. I feel like I don't know enough at all about security.

If you can make it in person and record the talk, I hope you put it on line. BTW, an intelink search didn't return anything for "postabon" except a soft drink firm.

Wish I could make that too, but Ottawa is a little out of my travel budget this year. Also, I'm only going to get to goto one or two conferences this year and I'm not that interested in BSDCan since I don't use free BSD beyond my wireless router. I enjoy reading your writings, so I'm looking forward to your video/slides. =)

Nice! I like your post Colin and will try to attend the conf and shoot the video for those who can't make it, if the conf doesn't make the video for you (hope there isn't copyright infringement though)

Reply on news.ycombinator.com