Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X25519 should be consistently supported where possible #42312

Open
vcsjones opened this issue Sep 16, 2020 · 3 comments
Open

X25519 should be consistently supported where possible #42312

vcsjones opened this issue Sep 16, 2020 · 3 comments

Comments

@vcsjones
Copy link
Member

I've noticed that currently, we have some partial support for X25519 ECDH on Windows:

ECCurve ecCurve = ECCurve.CreateFromFriendlyName("Curve25519");
using ECDiffieHellman ecdh = ECDiffieHellman.Create(ecCurve);

(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.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.Security untriaged New issue has not been triaged by the area owner labels Sep 16, 2020
@ghost
Copy link

ghost commented Sep 16, 2020

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley
See info in area-owners.md if you want to be subscribed.

@bartonjs bartonjs removed the untriaged New issue has not been triaged by the area owner label Sep 16, 2020
@bartonjs bartonjs added this to the Future milestone Sep 16, 2020
@vcsjones
Copy link
Member Author

vcsjones commented Sep 29, 2020

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?

@filipnavara
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants