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