[API Proposal]: NamedCurves should support Curve25519 and Curve448

[wsq003]

Background and motivation

NamedCurves currently support only nist and brainpool family, I believe Curve25519 and Curve448 should also be supported.

See also: https://en.wikipedia.org/wiki/Curve448
"In 2017, NIST announced that Curve25519 and Curve448 would be added to "Special Publication 800-186", which specifies approved elliptic curves for use by the US Federal Government"

see also: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves

API Proposal

namespace System.Security.Cryptography
{
	public struct ECCurve
	{
		public static class NamedCurves
		{
			public static ECCurve Curve25519 { get; }
			public static ECCurve Curve448 { get; }
		}
	}
}

API Usage

N/A

Alternative Designs

No response

Risks

Should be no risk.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

NamedCurves currently support only nist and brainpool family, I believe Curve25519 and Curve448 should also be supported.

See also: https://en.wikipedia.org/wiki/Curve448
"In 2017, NIST announced that Curve25519 and Curve448 would be added to "Special Publication 800-186", which specifies approved elliptic curves for use by the US Federal Government"

see also: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves

API Proposal

namespace System.Security.Cryptography
{
	public struct ECCurve
	{
		public static class NamedCurves
		{
			public static ECCurve Curve25519 { get; }
			public static ECCurve Curve448 { get; }
		}
	}
}

API Usage

N/A

Alternative Designs

No response

Risks

Should be no risk.

Author:	wsq003
Assignees:	-
Labels:	api-suggestion, area-System.Security
Milestone:	-

[vcsjones]

Putting Ed25519 and Ed448 on NamedCurves doesn't make sense to me. The majority of the platform implementations don't expose EdDSA in a way that fits the ECDsa or ECAlgorithm type. For example, ECParameters with D and Q don't really fit the "opaque key" of modern implementations of EdDSA. Nor can they implement SignHash, only SignData.

• We have a separate proposal for Ed25519 here. [API Proposal]: Add support for Ed25519 #63174
• We have a tracking issuing for X25519 X25519 should be consistently supported where possible #42312
• We have a broader issue for these at Proposal: Add Ed25519 and Curve25519 Algorithms to System.Security.Cryptography #14741

We don't have specific issue for Edwards448 but it usually comes up wherever we discuss Edwards25519.

[wsq003]

var ecdsa = ECDsa.Create(); ecdsa.GenerateKey(ECCurve.NamedCurves.ed25519); would be nice.

[bartonjs]

ecdsa.GenerateKey(ECCurve.NamedCurves.ed25519) doesn't make sense for a couple reasons:

1. ed25519 isn't a curve, it's an algorithm
2. The ed25519 algorithm isn't ECDSA, it's the "competing" EdDSA (big C to little d)
3. Windows doesn't support the DJB-proposed Edwards curves for ECDSA, only ECDH. (And EdDSA if they ever add that)

[bartonjs]

To my recollection, and reinforced by a few minutes' research, the neither of the /curves/ for Curve25519 or Curve448 have registered Object Identifiers (OIDs). (ed25519/ed448 and X25519/x448 as algorithm identifiers exist, but I can't find OIDs for those curves for using as the identifier for an id-ecdh SPKI/PKCS#8)

In addition to needing to solve the problem of what key export looks like (do we change from id-ecdh to id-x25519 just because the curve was Curve25519?), we'd need to solve the problem of how we communicate this curve back and forth to OpenSSL (when on Linux).

So, while I agree that the shape of the API is about as good as it would get... it can't currently be meaningfully implemented for our platform.

[vcsjones]

can't find OIDs for those curves for using as the identifier for an id-ecdh SPKI/PKCS#8)

RFC 8410 defines them as:

id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }
id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }

[bartonjs]

Yeah, those aren't curve identifiers, they're algorithm identifiers.

The sample certificate:

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

has tbsCertificate.subjectPublicKeyInfo.algorithm value of

SEQUENCE(
   OID:id-X25519
)

instead of

SEQUENCE(
    OID:id-ecPublicKey,
    OID:[some oid to identify the curve]
)

(or id-ecdh instead of id-ecPublicKey)

If OpenSSL will fetch the curve by 1.3.101.110 (translated to an OSSL-NID), then I guess we could use it... but why would we pick 110 over 112 for the same thing there (assuming they both work)?

The other major alternative would be to take the Windows approach and call it (FriendlyName:"Curve25519", OID:NULL), then hook it as a special case in ECDH (and make it fail in ECDSA)... and then hook that in all of our import and export routines. Ick.

[annerajb]

FYI

Nist finally published ed25519 and 448 as part of the fips 186-5 standard.

https://www.nist.gov/news-events/news/2023/02/nist-revises-digital-signature-standard-dss-and-publishes-guideline?utm_source=miragenews&utm_medium=miragenews&utm_campaign=news