AES Modes

[Eric Young]

Quoting Brian Gladman <brg at gladman.plus.com>:

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

Are you running on a P4?  ASM for sha1 on a P4 takes about 11.9 cycles 
per byte.  The P4 is a very touchy x86 implementation.
On most other architectures I nearly always see a bit less than 2 times faster
sha1 vs AES.  On AMD64, asm, I have
AES-cbc at 12.2 cycles per byte and sha1 at 6.8.  This is about
as good a CPU as it gets (IPC near 3 for both implementations).

eric


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