[openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch

[Linsell, StevenX]

> Date: Thu, 22 Sep 2016 15:39:13 +0000
> From: "Linsell, StevenX via RT" <rt at 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.Linsell at 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.