Okay, folks, pycryptopp is now working on one of our ARM CPU
buildbots, and I've run some measurements of the time to do different
crypto operations.
This machine has an ARM926EJ-S rev 0 (v5l) "Feroceon" at 266 MHz, with
32 KiB icache and 32 KiB dcache.
Here are a few crypto algorithm measurements:
Algorithm MiB/Sec Cycle/Byte
--------- ------- ----------
MD5 24 10.7
SHA-1 9 28.5
SHA-256 6 42.5
Salsa20/12 13 19.0
AES/CTR (128-bit) 2 131.9
(By the way, the SHA-3 project looks like it will produce a hash
algorithm at least as fast as SHA-256 on this sort of CPU. The
candidate which has the best performance on such a CPU so far is
"edonr256" which takes 17.5 cycles/byte on a similar ARM CPU:
http://bench.cr.yp.to/results-hash.html#arm-apollo .)
Algorithm millisec/Op megacycle/Op
--------- ----------- ------------
RSA 2056 Sig 950.00 252.70
RSA 2056 Verify 12.82 3.41
ECDSA secp256k1 Sig 49.05 13.05
ECDSA secp256k1 Sig/pre 31.56 8.40
ECDSA secp256k1 Ver 128.75 34.25
ECDSA secp256k1 Ver/pre 51.00 13.57
ECDSA secp192r1 Sig 32.90 8.75
ECDSA secp192r1 Sig/pre 16.95 4.51
ECDSA secp192r1 Ver 58.82 15.65
ECDSA secp192r1 Ver/pre 28.86 7.68
And here is the big issue -- the main reason why we're switching to
ECDSA in the next release of Tahoe-LAFS (not the imminent v1.5
release). It is the time it takes to generate a new key pair. (I
suspect that the RSA keypair generation in Crypto++ is not optimized.)
Algorithm millisec/new key
--------- ---------------
RSA 2056 31,670 (best)
RSA 2056 57,860 (mean)
RSA 2056 98,180 (worst)
ECDSA secp192r1 2.75 (best)
ECDSA secp192r1 2.79 (mean)
ECDSA secp192r1 2.89 (worst)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to
cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---