[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Counter Mode Security: Analysis and Recommendations



At 10:23 AM 11/21/2002 -0800, Bob Doud wrote:
>> >>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:
>> 
>>  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
>> 
>
>Correct Paul.  And stay tuned Alex... we'll be seeing VERY cost effective
>Gigabit security chip coming along soon.  It would just be nice to get
>these CTR mode issues nailed down soon so us chip guys can provide
>support for this mode!
>

OK. So each packet has an independent IV.  And frags are infrequent.
Although to be honest, how the datalink drivers deliver the packet bytes
can be all over the map, I suspect internal control block frags may be
all too common an issue to deal with.

Of course there's still the *minor* matter of the hash.  Unless I'm
mistaken, this still requires linear sequential processing of the packet
bytes.  Won't this disrupt the tidy flow of parallel blocks?

Cost is still a factor. Let's say you drive it in total to $25 per chip 
today.  This is $125 retail + $50 for 1 Gbps Ethernet hardware. That's 
a tough sell.

The really big win I see for AES-CTR is the fact you no longer need to add
padding to the packet.  That simplifies life considerably for writing a 
software driver/filter.

- Alex

--

Alex Alten
Alten@ATTBI.com

"I said be there.  
 And you crushed the stones to be there."  
            - Genghis Khan, 13th century