Missing elliptic curves

[tarcieri]

This is a tracking issue for additional elliptic curves we could potentially implement.

Note that we are presently focusing on short Weierstrass curves which can be implemented using the primeorder crate. There are many other Rust projects implementing newer curve forms, such as bls12_381, curve25519-dalek and ed448-goldilocks.

• Brainpool P-224 (brainpoolP224r1, brainpoolP224t1)
• Brainpool P-256 (brainpoolP256r1, brainpoolP256t1)
• Brainpool P-320 (brainpoolP320r1, brainpoolP320t1)
• Brainpool P-384 (brainpoolP384r1, brainpoolP384t1)
• Brainpool P-512 (brainpoolP512r1, brainpoolP512t1)
• NIST P-192 (secp192r1)
• NIST P-224 (secp224r1)
• NIST P-521 (secp521r1)
• GOST 34.10-2018
• secp224k1
• SM2

[tarcieri]

I added an initial set of Brainpool curves (bp256 and bp384) in #281 and #280 respectively.

Unfortunately I'm not a Brainpool user, so I was unclear around usage of brainpoolP256r1/brainpoolP384r1 vs brainpoolP256t1/brainpoolP384t1. The crates I added assume the former.

Happy to hear from Brainpool users about how the curves are used in practice. If it turns out *r1 is a mistake we can potentially transition over to *t1 or support both *r1 and *t1.

[tarcieri]

Circling back on Brainpool, I see a couple ways forward. We should decide which one makes sense.

First, for background:

• r1 curves are "verifiably pseudorandom" (or rather, were supposed to be but were erroneously generated)
• t1 curves are the "twist" curves and provide the same effective security properties but permit a slightly more efficient implementation due to the use of smaller parameters

So, it seems like we should probably support both r1 and t1, for both the 256-bit and 384-bit modulus sizes. Here are a couple of ways that could be done:

Include both r1 and t1 curves in the same crate

This would result in the following crates:

• bp256: brainpoolP256r1 and brainpoolP256t1
• bp384: brainpoolP384r1 and brainpoolP384t1

Separate crates for r1 and t1 curves

This would look like:

• bp256r1: brainpoolP256r1
• bp256t1: brainpoolP256t1
• bp384r1: brainpoolP384r1
• bp384r1: brainpoolP384t1

My vote would be for bp256 and bp384 crates for now, each containing both the r1 and t1 variants respectively.

They could be placed under r1 and t1 modules, e.g. bp256::r1 and bp256::t1

As it were, I went ahead and registered bp256r1, bp256t1, bp384r1, and bp384t1 just in case.

Edit: split r1 and t1 variants of bp256 and bp384 in #286

[kamulos]

I know it is not one of the most widespread curves, but is there any chance, that secp224r1 is supported at some point?

[tarcieri]

@kamulos it might be possible to support sometime after #218 lands

[pdeligia]

@tarcieri, I know that you mentioned in your original post that:

Note that we are presently focusing on "legacy" short Weierstrass curves. There are many other Rust projects implementing newer curve forms, such as curve25519-dalek and bls12_381.

But is there any chance (or are planning already) to implement the curve25519 natively in RustCrypto's elliptic-curves crate?

I know that someone can use curve25519-dalek, but I am mainly looking for a solution that plays along well with the RustCrypto elliptic_curve::PublicKey (and other related) APIs and especially the "parsing SPKI" feature. This would be super awesome, as I don't think with curve25519-dalek you can do something similar (i.e. parse from PEM/DER), nor that it interops with the elliptic-curves crate, unless I am missing something?

[tarcieri]

I assume you're specifically interested in Ed25519 and RFC 8410 support?

There's an open PR to add PKCS#8 and SPKI support to ed25519-zebra:

https://github.com/ZcashFoundation/ed25519-zebra/pulls

I'll also note that similar functionality is available through the signatory crate:

https://docs.rs/signatory/0.23.2/signatory/ed25519/struct.SigningKey.html#method.from_pkcs8_der

We do also maintain the ed25519 crate which is used by ed25519-dalek. I could potentially add support for decoding/encoding PKCS#8 and SPKI public keys and private keys to bytes:

https://github.com/RustCrypto/signatures/tree/master/ed25519

[tarcieri]

I added PKCS#8 support to the ed25519 crate in RustCrypto/signatures#381

It now provides a KeypairBytes type which can be decoded from/encoded into PKCS#8.

Note it's still unreleased though

[diachedelic]

Deno, a popular JavaScript runtime, uses RustCrypto's implementation of the P-256 and P-384 curves. A lack of support for the P-521 curve is the only thing holding it back from full compliance the WebCrypto standard, implemented by all major browsers. I humbly request the P-521 curve. Thank you very much!

[tarcieri]

Now that p384 is mostly good to go and based on what are hopefully reusable wrappers around fiat-crypto (#586), it might be possible to wrap their implementation of P-521's fields, although first I'll probably take a look at migrating the field implementations in p256 to also use fiat-crypto.

[kamulos]

Has the secp224r1 come any closer with the work? The #218 you mentioned last time seems to be abandoned.

[tarcieri]

Do you have a real use case for it?

Note that there's quite a bit of duplication between p256 and p384, and more work is needed to extract things like the addition formulas and make them generic around the underlying field elements, so we're still not in great shape to start supporting more P-curves.

If it's just p256, p384, and p521, things are a bit more manageable until more of the implementation can be provided generically.

[kamulos]

Sounds reasonable 👍

I need the curve for my company's product. Having this without importing one of the few C crypto libraries supporting it would be nice to have, but obviously I am aware that this is a quite exotic curve.