RE: Counter Mode Security: Analysis and Recommendations

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:

 Alex> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote:
 >> <snip>
 >> 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.
 >> 
 >> Bob
 >> 

 Alex> Really?  And all these expensive parallel hardware engines will
 Alex> still be effective on the receiving end when packets arrive out
 Alex> of order, are lost, duplicated or fragmented?  What about
 Alex> interleaved packet streams from different hosts? What about
 Alex> hash computations?

IPsec acts on IP datagrams.  So loss, duplication, or reordering of IP
packets clearly has no effect.

Fragments?  In IPv6 there are no fragments, obviously.  In IPv4, there
are no fragments either in settings where high performance is
expected.

 Alex> And who will buy them?  1 Gigabit/sec cards go for $50 today.
 Alex> The cheapest AES chips are $25 each, which is $125 retail.  You
 Alex> will need about 4 of them at least.  So now that card becomes a
 Alex> $500 card.  Ten times as expensive.  By the time they become
 Alex> cheap enough the world will be using 10 gigabit/sec Ethernet.

You seem to be assuming that the only way to get multiple AES units is
to buy multiple chips, and collect them on a board.  That's actually
the least likely approach.

All high speed crypto chips contain multiple cipher units inside the
chip.  Right now, with CBC mode, it's difficult to keep them all
working effectively, because any given packet has to be handled by a
single cipher unit due to the chaining.  With counter mode, such
multiple-unit chips can easily run at full speed even when acting on a
single packet stream, because each cipher block can be processed by a
separate unit.  In other words, a packet as short as 64 bytes can get
the performance gain of four cipher units working in parallel.

In high speed crypto chips, and especially with efficient ciphers like
AES, the crypto cores are not all that large a part of the whole
chip.  Control, embedded memory, bus interfaces, etc. all tie up large
parts.  So the incremental cost of a whole bunch of cipher units is
very much lower than you claimed.

     paul