### Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

On 5 Dec 2006, at 3:22 PM, Brian Gladman wrote: 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? That was using pgp --speed-test. It's an algorithm-level test, but it's calling the SDK so there's some API-level overhead involved. I got the number from a 3.0GHz x86, and it was 1.36 for encryption and 1.37 for decryption. But I also got the numbers from a 2GHz Core Duo laptop and it was 1.12 for encryption and decryption. On the other hand, the fast machine was encrypting AES-128 at 66389.45 KB/s and the slow one at 22217.39 KB/s, which means that the 3GHz machine is running at just shy of 3x the speed of the 2GHz machine! Obviously, there are other factors, such as cache, memory, and so on that are huge differences. I'd take a slowdown of 12% to 40% if I was getting a 300% base speedup. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

### Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

Jon Callas wrote: I just ran a speed test on my laptop. Here are some relevant excerpts: CipherKey Size Block Size Enc KB/sec Dec KB/sec -- -- -- IDEA 128 bits 8 bytes 24032.0924030.66 3DES 192 bits 8 bytes 10387.6710399.30 CAST5 128 bits 8 bytes 29331.1729459.49 Twofish 256 bits 16 bytes 20233.6319185.82 AES-128 128 bits 16 bytes 44100.2346266.98 AES-192 192 bits 16 bytes 39731.3341228.87 AES-256 256 bits 16 bytes 36017.9537302.43 Blowfish 128 bits 8 bytes 35347.3438311.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]

### Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...

David Johnston wrote: Jon Callas wrote: Moreover, AES-256 is 20-ish percent slower than AES-128. Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much data. So when implemented in hardware, AES-256 is substantially faster. AES-256 does not encrypt any more data per round than AES-128. My guess is that you are thinking about Rijndael with a 256 bit block and a 256 bit key. Brian Gladman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]