AES Modes
Brian Gladman
brg at gladman.plus.com
Tue Oct 12 13:17:41 EDT 2004
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
More information about the cryptography
mailing list