From rogaway@cs.ucdavis.edu Mon Mar 4 16:30:43 2002 Date: Fri, 16 Nov 2001 15:25:53 -0800 (PST) From: Phillip Rogaway To: stds-802-11@ieee.org Subject: AES modes: OCB vs. Generic Composition A couple of colleagues working on 802.11 forwarded the slides of a recent talk to me, and asked for comments. One asked if I might post my response to this newsgroup. (I'm not on this mailing list, so if there's something you'd like me to see you'll have to send it directly) -phil rogaway ------------------------------------------------------------- Thanks for forwarding to me the talk "AES Mode Choices: OCB vs. Counter Mode with CBC-MAC" by Ferguson, Housley and Whiting. I just took a look. I have to say that much of it is valid. While there are minor technical things that one can pick at, I agree with the overall point that CTR + CBCMAC is a viable alternative to OCB. Indeed I've always tried to be clear, whenever I've spoken about OCB, that the generic composition paradigm IS a perfectly good approach to authenticated encryption -- and, in fact, CTR + CBCMAC is my favorite pair of algorithms to use for generic composition based on a block cipher. I too suspect that, for hardware, in something like a wireless LAN card to stick into my laptop, it might all be a wash. In such a setting one has a modest target speed and either authenticated-encryption approach (OCB or CTR+CBCMAC) can rather easily be implemented to achieve that target speed. Apart from working at extremely high speeds (not relevant in the 802.11 space), OCB's main advantage over CTR + CBCMAC shows up in software, when you're trying to protect the processor from extra computational burden. There I've got to believe that a factor of two often does matter. In software, it's not really that "OCB 'wins' if 1x is fast enough, but 2x is too slow", as the Ferguson/Housley/Whiting talk says; it's more like, "Do we spend 15% of our available cycles on cryptography, or do we spend 30%"? (for appropriate constants '15' and '30', which are highly context-dependent). On the technical side: slide 6, cut round key table size in half, is wrong (the authors are forgetting that you need two keys for CTR+CBCMAC, and that the round keys for AES encryption and decryption are the same, combining to make this particular factor of two in favor of OCB); slide 9, I remark that, historically, people usually assume that cryptography will be mostly in hardware, and then it somehow winds up mostly in software; slide 10, I remark there are natural ways to extend OCB to allow authentication of arbitrary amounts of cleartext -- I've described some in a separate note -- so you're not going to "get stuck" should you later want to authenticate more than what you can do with nonce stealing; slide 11, two keys for OCB (on decrypt??) is misleading, as CTR+CBCMAC keys the block cipher with two different keys while OCB uses one; slide 13, "new is dangerous", obviously has some validity in the large, but this is a bit overstated for for a domain where there are no issues of definitional modeling, weak concrete security bounds, or the plausibility of the cryptographic assumptions; and, finally, slide 5, the bit of patent-bashing, "fair, non-discriminatory, and non-onerous are subjective", perhaps so!, but this is more an issue with the IEEE-patent-policy at large, and I think that I, for one, have been very fair, reasonable and co-operative about this stuff -- and I'd be extremely surprised if any other interested party would do otherwise. That's about it! With kind regards, Phil