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 <rogaway@cs.ucdavis.edu>
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