Re: Counter Mode Security: Analysis and Recommendations

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:

 Theodore> On Wed, Nov 20, 2002 at 04:37:57PM -0800, Bob Doud wrote:
 >> > >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
 >> <snip>
 >> > 
 >> > David> 4) is it acceptable to implement AES-192 or AES-256 and
 >> use > David> those ciphers for counter mode?  Or is it desirable
 >> to use > David> AES-128 for both CBC and counter mode?
 >> > 
 >> > I would hate to depend on AES-192 or above, since it's not clear
 >> to me > how widely those will initialy be implemented in high
 >> speed silicon.
 >> > 
 >> And let's keep in mind that a fundamental reason that we're
 >> pursuing counter mode in the first place is for high-performance
 >> as systems move into the multi-Gigabit range.  (Parallelizing the
 >> crypto operations across multiple engines with staggered
 >> counters.) It's safe to say that all hardware and software
 >> implementations will be noticably slower with AES-256 than with
 >> AES-128.

 Theodore> The speed hit to go from AES-128 to AES-192 is about 20%
 Theodore> (12 rounds versus 10 rounds).  But that's assuming that
 Theodore> folks feel this is actually necessary.

 Theodore> I want to make sure that everyone in the IPSEC working
 Theodore> group understands that the TMTO attack requires only
 Theodore> O(2**85) in time, but it also requires O(2**85) in space.

That's true.  But the real question is: do we want to have transforms
that have a work factor way below that of the underlying cipher, and
way below that of other transforms that use that cipher?  I believe
it's a basic rule of modern cryptography that you avoid ciphers, and
modes, which have a work factor less than 2^k for k bit keys.

As it stands, I see NO justification for the existence of AES-CTR
mode, in its current form, with 128 bit keys (the only sensible
transform with AES 128 bit keys is CBC).  Adopting David's proposal
will fix that, and make 128 bit keyed AES acceptable for AES-CTR.

     paul