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 [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
