> Date: Thu, 22 Sep 2016 15:39:13 +0000 > From: "Linsell, StevenX via RT" <r...@openssl.org>
> Running against master branch (commit > 39c136cc53d7b6fafdd1a0b52c035fd24358e01c - Updates CHANGES and NEWS > for new release) we see a failure when running openssl speed with the ecdh > parameter: > > ./openssl speed ecdh [SNIP] > ECDH failure. > 140194445354752:error:100AE081:elliptic curve > routines:EC_GROUP_new_by_curve_name:unknown > group:crypto/ec/ec_curve.c:3100: > 140194445354752:error:100AE081:elliptic curve > routines:EC_GROUP_new_by_curve_name:unknown > group:crypto/ec/ec_curve.c:3100: > OpenSSL 1.1.1-dev xx XXX xxxx I've had a bit more time to investigate this bug. The issue was introduced by commit: bc7bfb83b7189c052bf2898bd6b82f8e4b4fd3f6 Remove old EC based X25519 code. Committed on August 11th And is present in both OpenSSL_1_1_0-stable and master branch. OpenSSL speed uses the EC methods to measure ECDH_compute_key operations including support for the X25519 curve. Since the commit above the EC_KEY_new_by_curve_name call fails as X25519 is no longer supported. I would like to work on a fix for this but I would like some feedback on the direction to take. 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. Personally I would favour option 3 or possibly 4 depending on time constraints but I don't know if there is a historical reason why speed uses the low level API's? Is it so the speed measurements are focused tightly on the algorithm they are measuring or is it just they were written that way and nobody has had the need to change them? Any comments would be appreciated before I spend time on this. Kind Regards, Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
