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

[Jon Callas]

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 majordomo at metzdowd.com