[-SPAM-] Re: Can you keep a secret? This encrypted drive can...
Brian Gladman
brg at gladman.plus.com
Tue Dec 5 18:22:13 EST 2006
Jon Callas wrote:
> I just ran a speed test on my laptop. Here are some relevant excerpts:
>
> Cipher Key Size Block Size Enc KB/sec Dec KB/sec
> -------- -------- ---------- ---------- ----------
> IDEA 128 bits 8 bytes 24032.09 24030.66
> 3DES 192 bits 8 bytes 10387.67 10399.30
> CAST5 128 bits 8 bytes 29331.17 29459.49
> Twofish 256 bits 16 bytes 20233.63 19185.82
> AES-128 128 bits 16 bytes 44100.23 46266.98
> AES-192 192 bits 16 bytes 39731.33 41228.87
> AES-256 256 bits 16 bytes 36017.95 37302.43
> Blowfish 128 bits 8 bytes 35347.34 38311.22
>
> Comparing AES-128 and AES-256, encrypt speed is 1.2243959x and decrypt
> is 1.2403208x. So that makes my
> lick-your-finger-and-stick-it-in-the-wind rule of thumb of 20% slower
> okay. I'll try to say 20-25% in the future.
>
> Of course, though, implementation matters a lot. I'm running a PPC-32
> machine. You'll get different answers on an ia32, and different ones an
> AMD64.
For AES the round function and key scheduling cost per round are
basically the same for both AES-128 and AES-256. In consequence I would
expect the speed ratio to be close to the ratio of the number of rounds,
which is 14 / 10 or 40%.
My own figures on AMD64 are 1.35 for encryption and 1.39 for decryption.
And on a P4 they are 1.36 and 1.38 respectively. These are hence close
to the expected 40% figure.
This suggests to me that a figure around 20% would apply in applications
in which about half the time is spent in encryption and half in other
higher level activities.
Can I hence assume that your benchmark is being run at application level
rather than algorithm level? If not why is the ratio only 22% on the
PPC-32?
Brian Gladman
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list