Join forces?

[tarcieri]

Hello! I saw this crate and wanted to note there are a few other overlapping efforts here:

See the RustCrypto elliptic-curve crate and curve-specific crates implemented with it:

• https://github.com/RustCrypto/elliptic-curves/
• https://docs.rs/elliptic-curve

As an example of a curve implemented with it, there's the p256 crate:

• https://docs.rs/p256

These are used by the ecdsa crate:

• https://docs.rs/ecdsa

Note there's also the algebra crate which provides Field and Group traits:

• https://github.com/scipr-lab/zexe/tree/master/algebra

Anyway, I think it'd be good to collaborate on one solid set of crates for this particular problem, and open to discussing how!

[armfazh]

Definitely, this is something worth to do it.
I would like to know more about the guidelines of the project.
Whether it will include full-optimized code, arch-agnostic vs arch-dependent, pure rust vs FFI, assembler allowed?

Also, I think traits must be more granular.
Example: In the P256 crate, P-256 is a curve, there should not be keys on it. However, ECDH/ECDSA are algorithms that have keys.

This is a small example, of course, but I think Rust allows a fine-grained design that we can leverage to have good API's.

[tarcieri]

Whether it will include full-optimized code, arch-agnostic vs arch-dependent, pure rust vs FFI, assembler allowed?

The other crates in https://github.com/RustCrypto all provide a pure Rust portable implementation (written in a constant time-ish manner, assuming the underlying architecture has a constant time arithmetic instruction among a handful of other assumption), and then layer on top of that architecture-specific optimizations. We've used a handful of FFI-based linking to assembly in the past, but have largely stopped doing that going forward to instead use things like core::arch and packed_simd.

Example: In the P256 crate, P-256 is a curve, there should not be keys on it. However, ECDH/ECDSA are algorithms that have keys.

Beyond ECDSA, the notion of "keys" are also useful for things like D-H and ECIES, but also note that "keys" in that crate provide additional functionality over the values they wrap.

elliptic_curve::weierstrass::PublicKey acts as an abstraction over various possible Weierstrass curve point serializations which may be encountered "on the wire", including the compressed and uncompressed forms (for Weierstrass curves, these are the SEC1 "Elliptic-Curve-Point-to-Octet-String" serializations), at at least in the case of the p256 crate the ability to convert between them (i.e. compress/decompress points). They also provide a place to add things like PKCS#8 encoders/decoders.

For scalars, the elliptic_curve::SecretKey type also handles zeroization-on-drop and accidental disclosure of the secret scalar value.

[tarcieri]

Just wanted to note we have full scalar, field, and curve arithmetic support in both the p256 and k256 crates including point compression/decompression, the group operation (i.e. addition), as well as scalar multiplication, implemented in terms of the complete Weierstrass formulas.

I am looking at adding support for computing ECDSA generically over any Weierstrass curve.