Openssl: OpenSSL 1.1.0 X25519 implementation

Created on 8 Dec 2016  路  3Comments  路  Source: openssl/openssl

I'm trying to develop an application that uses X25519 (or ECDH over Curve25519), which is supposed to be supported since version 1.1.0 (issue #309). But, when looking for examples, I realised that in the code this curve is not tested under test/ecdhtest.c. Literally:

     * Skipped for X25519 because affine coordinate operations are not
     * supported for this curve.
     * Higher level ECDH tests are performed in evptests.txt instead.

In test/evptest.c it is only tested that the generated secret key is what was expected. There is no key generation.

Another test that I tried to do was to run openssl speed ecdhx25519, which crashes:

ECDH failure.
139633730975552:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100:
139633730975552:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100:
OpenSSL 1.1.0  25 Aug 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) 
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -Wa,--noexecstack
                              op      op/s
 253 bit ecdh (X25519)   0.0000s      inf

It works perfectly with whichever another curve. I've tried to run the same with two versions (1.1.0 and 1.1.0c) and on two different machines, with identical result.

So, is X25519 _100%_ supported in 1.1.0? If so, where is my mistake?

Most helpful comment

Due to the way X25519 is defined in various standards it behaves differently from other curves. It is not accessible through the EC API for example. It is treated as a distinct "top level" algorithm that supports key generation and key agreement. So to generate a key you create a new EVP_PKEY_CTX with NID_X25519 and call keygen on it instead of via EVP_PKEY_EC. Via the command line: "openssl genpkey -algorithm X25519" does the trick.

All 3 comments

Due to the way X25519 is defined in various standards it behaves differently from other curves. It is not accessible through the EC API for example. It is treated as a distinct "top level" algorithm that supports key generation and key agreement. So to generate a key you create a new EVP_PKEY_CTX with NID_X25519 and call keygen on it instead of via EVP_PKEY_EC. Via the command line: "openssl genpkey -algorithm X25519" does the trick.

@snhenson Thanks for your reply. But, as far as I understand, the openssl speed command uses the API. Since there is already a sub-command for this curve, does it imply that an API-accessible version will be released in future versions?

I know this is closed but for info the speed bug you mention was fixed in the master branch by the following pull request:
https://github.com/openssl/openssl/pull/1658
This fix was not backported to the OpenSSL 1.1.0 branch, I think as it was considered a change that added a 'feature' i.e. it moved the ECDH speed tests to use the higher level EVP API rather than the low level EC API. Released branches will only take bug and security fixes not new features.
Hope that helps!

Was this page helpful?
0 / 5 - 0 ratings