RE: Counter Mode Security: Analysis and Recommendations

[Paul Koning <pkoning@equallogic.com>]

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

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

I have no idea what you're talking about.

Obviously, it's possible to design an OS and its drivers so as to
achieve poor performance.  It's also possible to design it for good
performance.  Take your pick.

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

Yes, which is why people keep looking for faster hashes.  Note also
that in the past, encryption has generally been substantially slower
than the authentication hash, so a speedup of the encryption transform
translated directly into a speedup of the overall processing.

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

Maybe, maybe not; depends on the system cost and the value of the
data.  In any case, you're talking about the cost of crypto in general
here; counter mode is certainly no worse, and most likely better, than
the others.

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

Not a chance.  For one thing, you still need padding (to a multiple of
4 bytes, standard ESP encapsulation rule that applies to all
transforms unless they have a higher requirement).  For another, the
total effort to do padding amounts to perhaps 20-30 lines out of
several thousand.

	paul