Proposal: Add Ed25519 and Curve25519 Algorithms to System.Security.Cryptography

[janhenke]

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.

[saper]

Definitely a good idea.

Daniel J. Bernstein "Can anything do better than elliptic curves?"

Daniel J. Bernstein papers on Curve25519

[ellismg]

/cc @sandkum, @bartonjs, @nguerrera

[guardrex]

Is asking for SHA256Cng for dnxcore50 related? ... mean in the sense of keeping community requests for expanded System.Security.Cryptography in the same issue, or should I ask in a separate issue? It's probably going to be needed for ADAL (source1, source2).

[ellismg]

I would prefer if you open another issue. Thanks!

[bartonjs]

@guardrex That'd be a separate issue 😄.

[janhenke]

Is this issue being worked on? Is any further information necessary?

[bartonjs]

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]

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]

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]

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]

Is there any movement on this? Found a good looking library but it requires Span so waiting for that https://github.com/ektrah/nsec

[damccull]

Yeah, I'm also really interested in this. I've found several implementations in C# (including a port of a java implementation by Whisper Systems) but I would rather have one I can trust as legit. I mean, I trust Whisper Systems, but I disagree with gplv3 and they have licensed it there...plus I'm not sure I trust the company that ported it to C#.

So...we can has curve25519?

[bartonjs]

curve25519 will work as a named curve on Windows when ECDiffieHellman is added. It won't "just work" on Linux because OpenSSL keys curves by OID and curve25519 doesn't have an OID, but it can be created from parameters. It won't work at all on macOS because Security.framework only supports secp224r1, secp256r1, secp384r1 and secp521r1 (and not explicit curve parameters).

[Meai1]

I hope this makes it soon into .NET Core 3 because as I understand it, all the other cyphers are actually not really considered secure anymore. There is pretty much only Curve25519 and it isnt supported in aspnet core yet... but maybe the larger point here is that I cant see the use of these enumeration values.
I need to know what they mean compared to OpenSSL ciphersuite strings and since dotnet core apparently uses OpenSSL in the background anyway, why hide this information? There should really be some kind of helper method on the sslfeature saying ToOpenSSLCiphersuiteString() so I know what is actually coming in.

I really dont understand why the enums are so imprecise. ExchangeAlgorithmType.DiffieHellman could mean almost anything. Likewise RsaKeyX is not a term used anywhere except in .NET apparently. What's the point of these namings?
Look at these here with the green checkmarks: http://safecurves.cr.yp.to/
How am I supposed to figure out in any reasonable timeframe what .NET supports. Not only that: What .NET supports in combination with: TLS version. OpenSSL version. Does dotnet bundle the openssl version? (Apparently not, which is likewise dangerous to me because if you work with openssl, you will know that every app is going to need a slightly different version and now good luck figuring out which one .NET loads at runtime)

[bartonjs]

as I understand it, all the other cyphers are actually not really considered secure anymore.

If you mean TLS ciphersuites, what .NET exposes as a platform and what it can do via TLS aren't the same thing.

As for the security of other ECC curves, all I can say is that the "SafeCurves" critera are written by the same person who proposed Curve25519 and that the TLS 1.3 RFC has secp256r1 as a mandatory support curve, and curve25519 as optional.

but maybe the larger point here is that I cant see the use of these enumeration values. ... Likewise RsaKeyX is not a term used anywhere except in .NET apparently. What's the point of these namings?

Assuming you're talking about ExchangeAlgorithmType, the enum was based off of SSL 2/SSL 3, before ECC was in use. A new issue asking for clarity on that enumeration (or other SslStream data enumerations) would be reasonable, but doesn't really belong in this issue.

Does dotnet bundle the openssl version?

No, .NET on Linux always uses the system managed version of OpenSSL.

(Apparently not, which is likewise dangerous to me because if you work with openssl, you will know that every app is going to need a slightly different version and now good luck figuring out which one .NET loads at runtime)

Most systems have at most two system versions of OpenSSL: 1.0.x or 1.1.x. (Or they'll also have LibreSSL, which claims to be OpenSSL 42). Those two are not compatible with each other, and can be both loaded into a process at once if needed.

.NET Core 2.1 and 2.2 prefer OpenSSL 1.0 when it's available, but use 1.1 if OpenSSL 1.0 isn't found (because when they were released they didn't understand OpenSSL 1.1, so adding it as a fallback is a more compatible in-place update).

.NET Core 3.0 prefers OpenSSL 1.1, but will use OpenSSL 1.0 when needed.

What .NET supports in combination with: TLS version.

SSL 2 is not supported on Linux. SSL 3 is dying. TLS 1.0, 1.1, and 1.2 are supported on all Linux distros, AFAIK. TLS 1.3 is available on distros which have OpenSSL 1.1.1 as a system library.

There should really be some kind of helper method on the sslfeature saying ToOpenSSLCiphersuiteString() so I know what is actually coming in.

SslStream in .NET Core 3.0 exposes the TLS ciphersuite negotiated via the new NegotiatedCipherSuite property. It returns an enum whose members are all named the IANA name of the ciphersuite, not the OpenSSL version (the OpenSSL version is usually the IANA one, but replace _ with - and drop the TLS_ prefix).

Any further discussion of TLS specifically should be a different issue; this issue is about exposing Curve25519 into the ECDiffieHellman class at runtime, and/or the algorithm EdDSA.

[Meai1]

well just to show you, here are the results of what Google uses: https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=216.58.195.78&hideResults=on

Every single cipher suite that they enabled uses ECDH x25519. Not a single secp256r1 to be found. I think they probably picked this optional curve for good reason over the mandatory one, we can only speculate here but the internet is definitely saying that x25519 is better than secp256r1 and Google seems to agree.

[gradx]

Bump. Can we add X25519 and Ed25519 to the roadmap?

[YasarYY]

Despite there is no official support/documentation, I've defined the Curve25519 as a custom curve on .NET Core 3.1. And used ECDiffieHellman for key pair generation and shared secret calculation, constituting what's known as X25519.

As a counterpart, I used another crypto library over a different platform, for verification. (x-cube-cryptolib over stm32f103c8 dev board)

ECDiffieHellman/Curve25519 somehow generates correct key pairs and shared secret, which are coherent with the control library, even when curve's definition parameters are wrong. That is something which I didn't expect. I don't know how reliable this is but it works. Weird though...

For codes and details, stackoverflow question is here.

[YasarYY]

About Ed25519, this curve can be defined and used in .Net Core as described in this stackoverflow answer.

But this is working only on Windows 10. I would recommend using .Net Core-compliant libs like NSec or libsodium-core.

[matbech]

About Ed25519, this curve can be defined and used in .Net Core as described in this stackoverflow answer.

But this is working only on Windows 10. I would recommend using .Net Core-compliant libs like NSec or libsodium-core.

Thank you for that. I would be nice if someone could do some performance benchmarks. My guess is that the generic approach Microsoft takes with the custom curves is significantly less performant than the other optimized options.

[alexandrehtrb]

Hello,
I am interested in contributing with Ed25519 algorithm for .NET, is there any way I can help? Do algorithms like this need to be exclusively interoped with the operating system?
ED25519 is a nice algorithm and it's the one recommended by GitHub. It would be great for signing JWTs and for SSH keys.
(a bit off-topic, it would be very good if Azure DevOps accepted ED25519 SSH keys, currently, it does not)

[bartonjs]

Do algorithms like this need to be exclusively interoped with the operating system?

Yep. On Windows our only crypto provider is Windows CNG (or Windows CAPI for the legacy CAPI types). On Linux it's only OpenSSL, and on macOS it's ideally Security.framework because one of these days I'm really truly going to rip the band-aid off and no longer support OpenSSL from macOS.

To my recollection, at least two of those don't have EdDSA at this time.

[saper]

OpenSSL 1.1.1 supports EdDSA with the Ed25519 and Ed448 curves

[TriHyde]

Does libSystem.Security.Cryptography.Native.OpenSsl pass the calls to the actual openssl installed into the system or is that a full implementation of the openssl API? Is that library closed-source?

[bartonjs]

Does libSystem.Security.Cryptography.Native.OpenSsl pass the calls to the actual openssl installed into the system?

Yes, libSystem.Security.Cryptography.Native.OpenSsl just handles loading the system OpenSSL and managing some more complex calls from managed code into native code.

[annerajb]

Do algorithms like this need to be exclusively interoped with the operating system?

Yep. On Windows our only crypto provider is Windows CNG (or Windows CAPI for the legacy CAPI types). On Linux it's only OpenSSL, and on macOS it's ideally Security.framework because one of these days I'm really truly going to rip the band-aid off and no longer support OpenSSL from macOS.

To my recollection, at least two of those don't have EdDSA at this time.

so does this mean that this proposal is blocked until both Windows and MacOS support ed25519?

Can we move the proposal forward even if it only works on linux with openssl 1.1?

if so what is the next step for this proposal?

[annerajb]

@bartonjs are you the right person or can you refer me to who can assist with this?

Seems to be stuck in limbo :(

[annerajb]

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]

Any news? I'd really like to see non nist curves in .NET

[bartonjs]

Any news? I'd really like to see non nist curves in .NET

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]

Any news? I'd really like to see non nist curves in .NET

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.

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]

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]

Any news on the topic? Would be really great to migrate some Java security workloads to .NET.

[bartonjs]

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]

Any update on this?

[vanbukin]

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.