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 [EMAIL PROTECTED]
