SSL negotiation (where the device is the server) takes about 2s as it currently stands, and that's with the current MIPS assembler support in OpenSSL.I grabbed openssl-SNAP-20120917 ... ./openssl-generic32 speed aes-128-cbc sha rsa1024 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 192.15k 639.49k 1709.12k 2902.92k 3385.66k aes-128 cbc 1114.94k 1180.75k 1197.42k 1192.74k 1096.80k sha256 145.81k 468.03k 942.52k 1262.14k 1358.08k sha512 3749.33 14.97k 20.57k 27.62k 30.72k sign verify sign/s verify/s rsa 1024 bits 0.363571s 0.011161s 2.8 89.6 ./openssl-mips32r2 speed aes-128-cbc sha rsa1024 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 297.78k 964.57k 2479.43k 4027.96k 4487.91k aes-128 cbc 1284.54k 1369.60k 1392.86k 1396.18k 1272.49k sha256 239.27k 666.35k 1385.98k 1897.49k 2035.75k sha512 3752.82 14.99k 20.50k 27.65k 30.72k sign verify sign/s verify/s rsa 1024 bits 0.135811s 0.009086s 7.4 110.1 Thanks!
Thank *you*! I was expecting a bit better performance (in absolute terms), but it might be limited by interface to external memory. At least sha512 performance is exceptionally bad and it surely depends on poor external memory performance. I mean it has to keep data in memory more than any other algorithm in question and that's what is likely to hurt it that much. It should be only few times slower than sha256 (e.g. 2.2 was observed on R5000), not *60* as you measured. >2x improvement in rsa1024 is also unexpected, but the other way, it more than expected, so that one can't complain here...
Now to the original question. You said that SSL negotiation takes 2s (server side you said, assuming RSA, i.e. RSA sign is dominating), and it's open question if it's fast enough for your purposes. If you are using 1024-bit key, then it should go faster. 2s probably means that you're spending notable portion of the time elsewhere, most likely synthesizing randoms. The datasheet you referred to mentions that the microcontroller in question has TRNG and it definitely should improve situation if you find a way to utilize it. If it's longer key we're talking about, then... Well, as mentioned, CPU in question implements SmartMIPS extension, which means that there is room for further improvement. It's hard to estimate... https://www.mips.com/products/processor-cores/classic/mips32-4k/ mentions 15ms for rsa1024 sign at 200MHz, which is >4x better than above result (scaled for 96MHz)... Well, it might be possible if one implements dedicated procedure targeting specifically 1024-bit key operations (modulo security counter-measures implemented in OpenSSL), otherwise 2x is probably more feasible for general case...
Datasheet also mentions that CPU in question has support for hardware AES-128. It would surely make difference if one manages to utilize it. Just keep in mind that in such case hash function would be the limiting factor. I mean if encryption gets a lot faster, you still have to hash the data, so you won't be able to break ~4.5MBps for SHA1.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
