> > There are several options which have varying impacts on what speed would > actually be measuring, I'll outline them below: > 1) I just remove X25519 support from OpenSSL speed. This is the easiest > fix but means nobody can use speed to measure performance with the X25519 > curve anymore. This would be undesirable as the curve is becoming > increasingly popular and well supported as an alternative to NIST curves. > 2) I add a special case to the ECDH measurement function that uses the > EVP_PKEY_* interfaces just for the X25519 curve. This adds complexity to > speed and means X25519 is technically not really comparable with the other > curves due to a different API entry point at a higher level. > 3) I move all the ECDH curves in speed over to use the EVP_PKEY_* > interfaces. This will make the curve measurement comparable but not with > historical data from earlier openssl versions (this may not be important > anyway). > 4) I go the whole hog and move all the pkey operations that I can in speed > over to use the EVP_PKEY_* interfaces. Again this would break historical > comparisons.
I just noticed this thread: I was already working on option number 3 for a side project where I had the need to compare benchmarks of ECDH with different curves, including X25519, so [here is a pull request][0] to start from if we want to revise which interface to use to access EC crypto in apps/speed. Hope this might save some time! Kind regards, Nicola Tuveri [0] https://github.com/openssl/openssl/pull/1658 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4683 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev