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

2006-12-08 Thread 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 [EMAIL PROTECTED]


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

2006-12-06 Thread Brian Gladman
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...

2006-12-04 Thread Brian Gladman
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]