Repository navigation
Proposal: Add Ed25519 and Curve25519 Algorithms to System.Security.Cryptography #14741
Description
The System.Security.Cryptography namespace contains several commonly used cryptographic algorithms. I propose the addition of two commonly used algorithms which are currently missing:
- Ed25519 is an implementation of an Edwards-curve Digital Signature Algorithm.
- Curve25519 is an algorithm designed to be used with elliptic curve Diffie-Hellman (ECDH) key exchange algorithm.
Both are based on the same elliptic curve. Many open source projects (e.g. OpenSSH, OpenBSD) seem to prefer this elliptic curve for use in elliptic curve cryptography (ECC). It is therefore beneficial to have these algorithms implemented in CoreFX.
The two algorithms should be included in the existing classes in the System.Security.Cryptography namespace, but it must be possible to explicitly ask for the usage of these algorithms.
Reacted by Cory Nelson, Jan Henke, Benedikt Radtke, Martin, Sanders Lauture, Eugene Moroz, lcsondes, Meai1, Fraser Ashyggton, Jasper and 54 more
Reacted by Evgeniy Alexandrov, Mrgaton and Daniel Florescu
Activity
saper commentedon Jun 19, 2015
Definitely a good idea.
Daniel J. Bernstein "Can anything do better than elliptic curves?"
Daniel J. Bernstein papers on Curve25519
ellismg commentedon Jun 19, 2015
/cc @sandkum, @bartonjs, @nguerrera
guardrex commentedon Jun 20, 2015
Is asking for SHA256Cng for dnxcore50 related? ... mean in the sense of keeping community requests for expanded
System.Security.Cryptographyin the same issue, or should I ask in a separate issue? It's probably going to be needed for ADAL (source1, source2).ellismg commentedon Jun 20, 2015
I would prefer if you open another issue. Thanks!
bartonjs commentedon Jun 20, 2015
@guardrex That'd be a separate issue 😄.
janhenke commentedon Aug 7, 2015
Is this issue being worked on? Is any further information necessary?
bartonjs commentedon Aug 7, 2015
The good news is that no further information is necessary 😄. The bad news is that we're currently focused on getting cross-platform support caught up to the existing API, so no one is working on this currently.
Once we have cross-plat caught up, then we'll move on to new functionality in lockstep; and the first "new" thing that I can think of would be to start pulling over the elliptic curve types from the full framework (which, since we're borrowing code from full framework, isn't really new 😄). And once that's done this becomes actionable.
So, hopefully that makes sense... it's definitely on the radar, but not quite yet on the schedule.
janhenke commentedon Aug 7, 2015
Okay, I hope we can finish FreeBSD support in CoreFX soon then. I was just asking to make sure this topic is not forgotten.
bartonjs commentedon Oct 3, 2016
Curve25519 should be usable once dotnet/corefx#8158 is completed (since it's an ECDH-only curve); but since it doesn't have a registered OID it isn't a first-class citizen. (It should work on Windows via a named curve using
new Oid(null, "curve25519")since Windows does by-name lookup; but OpenSSL does by-value lookup and therefore can't discover it).Ed25519 being a completely different algorithm will require more/unique work.
karelz commentedon Nov 16, 2016
We need API proposal for each algorithm.
Keep in mind that each new algorithm has to receive Microsoft crypto-board approval - we can help get it started, but there is no guarantee about the result.
andymac4182 commentedon Dec 15, 2017
Is there any movement on this? Found a good looking library but it requires Span so waiting for that https://github.com/ektrah/nsec
22 remaining items
annerajb commentedon Dec 28, 2021
I wrote a proposal here.
I also have a fork where i did a lot of this work and got x509certificates and sslstream to happily load the private key from openssl.
Assuming that it's fine to implement this for a single platform (since it seems it has bene done before with a few other algorihtms)
#63174
mnns commentedon Jan 22, 2022
Any news? I'd really like to see non nist curves in .NET
bartonjs commentedon Jan 22, 2022
There are already a lot of non-NIST curves... the brainpool curves: https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.eccurve.namedcurves?view=net-6.0
Curve25519 also works for ECDH, on Windows. Ed25519 is a different algorithm, and not supported in enough of our platforms to provide enough
usefulness / frustration.Fabi commentedon Jun 23, 2022
It's used in many places nowadays and it's a no go to not have support for it in .net (This includes Ed25519ph and Ed25519ctx)
anner-emed commentedon Jul 19, 2022
Another example in case we where short on any.
Microsoft entra verified credentials only supported algorithms
https://docs.microsoft.com/en-us/azure/active-directory/verifiable-credentials/verifiable-credentials-standards#supported-algorithms
zeroskyx commentedon Sep 16, 2023
Any news on the topic? Would be really great to migrate some Java security workloads to .NET.
bartonjs commentedon Sep 19, 2023
We have an approved API shape at #63174. But during implementation we found Apple's implementation to be non-conformant. Since we don't do crypto ourselves (for many reasons, including that government agencies don't like JITted crypto) and we don't add things in crypto unless they run on two major platforms, and since Windows doesn't do EdDSA/Ed25519... we put the plan on hold again.
Curve25519+ECDH works fine on Windows, but not on Linux or macOS. (That's not an exception to the above, it's just that Windows supports that curve as a named curve and the others don't... so it falls under "we added support for named curves")
ybot01 commentedon Nov 2, 2023
Any update on this?
vanbukin commentedon Nov 15, 2023
I want to highlight a use case for Ed25519. At the moment, I am working on implementing a library for Passkeys (WebAuthn) on the side of the Relying Party (forming parameters and validating responses on the backend of an ASP.NET Core application). To pass Fido Conformance, support for the Ed25519 algorithm is needed on the library side. The only implementation of Fido2 for .NET uses the third-party library NSec.Cryptography, which provides a set of bindings for libsodium with a managed wrapper around them. Since this directly affects security, it would be much better to use cryptography from BCL, not from third-party implementations.
UPD.
A moment of self-promotion: the library is ready
https://github.com/dodobrands/WebAuthn.Net
DennisDyallo commentedon Jun 23, 2025
Watching this
revert: remove non-existent .NET 9.0 X25519 wrapper
Replace placeholder documentation comments (#37)
vcsjones commentedon Apr 27, 2026
I am going to close this because there are other issues tracking this work in better detail