RE: Counter Mode Security: Analysis and Recommendations

[Stephen Kent <kent@bbn.com>]

Alex,

><SNIP>
>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.

The avoidance of padding for block fill is useful, but the raw 
performance of CTR mode is a very big attraction.  The integrity 
check is likely to be the limiting factor with CTR mode, but 
integrity algorithms are separate from encryption algorithms in most 
current uses.  Some combined modes make use of integrity algorithms 
are amenable to parallelism.

Steve