You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Windows calling it "Curve25519" is unfortunate, but, I digress.) Windows can't yet work with these in X.509 due to a lack of implementation of RFC 8410, but the crypto primitive works.
OpenSSL does have X25519 support as well, but it is not implemented the same as the other EC functionality. Specifically, we are using the EC_KEY functionality (EC_KEY_new_by_curve_name and friends) but these do not work with X25519. Using EVP_PKEY_CTX_new_id does work with X25519, but returns a PKEY, not an EC_KEY.
Ideally, X25519 would work on Linux as well.
The text was updated successfully, but these errors were encountered:
I noodled with this last night and during lunch, I have a very "happy path" case working but it's definitely a non-trivial task.
If we want to keep it in the ECDiffieHellman class (which would make some sense since that is where Windows works today) it probably makes sense to introduce (yet another) level of abstraction within ECDiffieHellmanOpenSsl that works with either EC_KEY or EVP_PKEY. Even if we rewrite as much as possible in terms of EVP_PKEY (which I've done, so far), EC_KEY doesn't go away completely, especially when we need to work with importing and exporting parameters. This would also be a cleaner separation of "what is supported and what isn't" since X25519 and much of the PKEY functionality we want is in 1.1.1.
Other things to think about are what to do with APIs that don't make sense with X25519, like how to deal with ECParameters. OpenSSL doesn't give us an X,Y for X25519, it gives us U (or X).
@bartonjs Just curious, do you have a feeling on customer demand for X25519?
The implementation on Windows doesn't seem to accept ECPoint with only X/U coordinate (with Y/V set to zeros). The high level protocols like OpenPGP use representation with X/U for key transfer which makes it difficult to use ECDiffieHellman to interoperate.
I've noticed that currently, we have some partial support for X25519 ECDH on Windows:
(Windows calling it "Curve25519" is unfortunate, but, I digress.) Windows can't yet work with these in X.509 due to a lack of implementation of RFC 8410, but the crypto primitive works.
OpenSSL does have X25519 support as well, but it is not implemented the same as the other EC functionality. Specifically, we are using the
EC_KEY
functionality (EC_KEY_new_by_curve_name
and friends) but these do not work with X25519. UsingEVP_PKEY_CTX_new_id
does work with X25519, but returns a PKEY, not an EC_KEY.Ideally, X25519 would work on Linux as well.
The text was updated successfully, but these errors were encountered: