AES Modes

[Brian Gladman]

Ian Grigg wrote:

> Jack Lloyd also passed along lots of good comments I'd
> like to forward (having gained permission) FTR.  I've
> edited them for brevity and pertinence.

[snip]
>  >>I'm obviously being naive here ... I had thought that the combined 
> mode would
>  >> be faster, as it would run through the data once only, and that AES 
> seems to
>  >> clip along faster than SHA1.
> 
> AFAIK all of the modes that use only one block cipher invocation per 
> block of
> input are patented. EAX+CCM both use two AES operations per block, and
> byte-for-byte SHA-1 is 2-5x faster than AES (at least in the 
> implementations
> I've seen/used/written), so using AES+HMAC is probably going to be 
> faster than
> AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES 
> chips
> and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of 
> course
> be much faster than SHA-1.

Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 
at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 
cycles per byte.

So I would put these two algorihms at about the same speed in C. In 
consequence I rather suspect that the 'two encryptions per block' cost 
might also apply to combined modes when AES is used with HMAC-SHA1.

Rich Schroeppel's CS mode has been added to the NIST modes list earlier 
this year and is not patented. It seems to have a cost that is close to 
'one encryption per block' but it has the 'interesting' property of 
using the internal 'mid-point' state of the cipher algorithm that is in use.

    Brian Gladman


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com