[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