Runtime: 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 :smile:.

[janhenke]

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

[bartonjs]

The good news is that no further information is necessary :smile:. 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 :smile:). 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.