RustCrypto elliptic-curves: one crate per curve, all no_std

General purpose ECC, split into many crates

The repository provides general purpose Elliptic Curve Cryptography support, including types and traits for representing various elliptic curve forms, scalars, points, and public and secret keys composed thereof. The key architectural decision is that all curves reside in separate crates, so you depend on the curve you actually use rather than on a bundle. Each of them is implemented using traits from the elliptic-curve crate, which is the shared abstraction layer, and the crates in this repository do not require the standard library, so they are no_std capable and can be used for bare-metal or WebAssembly programming. The workspace manifest lists what is built together:

[workspace]
resolver = "2"
members = [
    "bignp256",
    "bp256",
    "bp384",
    "ed448-goldilocks",
    "hash2curve",
    "k256",
    "p192",
    "p224",
    "p256",
    "p384",
    "p521",
    "primefield",
    "primeorder",
    "sm2",
    "wnaf",
    "x448"
]

That combination is the reason to reach for this workspace rather than a general purpose library: the crates are small, the dependency tree is shallow, and nothing pulls in an allocator or an operating system layer you do not want. The primary language is Rust, the default branch is master, and the last push was on 2026-10-16.

The curve list, and the ones people actually reach for

The crate table covers the usual suspects and a few that are less common. The NIST curves are p192, p224, p256, p384 and p521, with p256 the one most projects want. There is k256 for secp256k1, which is the curve Bitcoin and a lot of other systems use, and the repository topics list ecdsa, schnorr and taproot alongside it. The brainpool curves appear twice, as bp256 for the r1 and t1 forms of P256 and bp384 for the r1 and t1 forms of P384. There is sm2 for the Chinese SM2 standard, and the 448 and 521 families appear in their Goldilocks and Edwards forms, with ed448-goldilocks, x448 and the bign variant called bignp256. Two crates are not curves at all: hash2curve, which is the hash-to-curve construction, and wnaf, which is the windowed non-adjacent form arithmetic that the other crates use internally.

primefield and primeorder are where the arithmetic lives

The two directories that are not curve crates are the ones worth understanding, because they carry most of the code and most of the audit surface. primefield is the field arithmetic, the implementation of a prime field over a chosen underlying integer type, and primeorder is the scalar arithmetic for the order of the curve's group. Every curve crate is built on top of them, which is why the workspace patches them back to local paths rather than pulling them from the registry. The rest of the sharing is done through the elliptic-curve crate, which supplies the traits, and the effect for a user is that adding a curve to your dependency tree brings a field implementation, an order implementation and a curve specific layer with it. The cost of that design is that a dependency on a curve is not as small as it looks, and the benefit is that every curve in the ecosystem shares one field implementation rather than each having its own.

A workspace with its own lint policy

The workspace manifest is unusually explicit about the code quality rules, and it is worth reading as a statement of what this project considers acceptable in cryptographic code. The lints are declared at the workspace level and are set to warn rather than deny, but the list is long and specific: unchecked conversions, cast lossless, cast possible truncation, cast possible wrap, cast precision loss and cast sign loss are all warned, as are checked_conversions, implicit saturating sub, map unwrap or, missing errors documentation, missing panics documentation and missing must use candidates. The rust lints are just as pointed, with missing copy implementations, missing debug implementations, missing documentation, trivial casts, unused lifetimes and unused qualifications. Two entries stand out for what they say about a crypto library: undocumented unsafe blocks and unwrap in result are both warned, and unnecessary safety comments as well. The development profile also sets opt-level to 2, so debug builds are not the slow unoptimised builds you would get by default.

The patch section is a release hazard to know about

The workspace manifest ends with a patch section for crates.io that redirects six of the crates to local paths: ed448-goldilocks, hash2curve, primefield, primeorder and wnaf. That is how the workspace builds as a whole, but it has a consequence for anyone publishing a crate that depends on one of them, because a published crate that depends on primefield or primeorder at a version that has not been released on the registry will not resolve for consumers. The practical advice is to depend on the curve crates as they appear on crates.io rather than on the workspace, and to check the dependency versions of the crate you pick. The workspace also carries a Cargo.lock, a clippy.toml, a .typos.toml and a codecov.yml, so the lints, the spell checker and the coverage tracking are all configured in the repository rather than left to each contributor's own setup.

Rust 1.85, a dual licence and a tracking issue for the rest

All crates in the repository support Rust 1.85 or higher, and the minimum supported Rust version can be changed in the future but will be done with a minor version bump, which is the policy statement that matters for a dependency you are not going to update often. The licence is dual, Apache License version 2.0 or the MIT licence at your option, and contributions are dual licensed the same way unless the contributor states otherwise. The badge at the top of the readme points at a Rust version requirement of 1.85 or higher, and the chat link goes to a Zulip stream for the elliptic curves project rather than to a mailing list or a Discord server. For curves beyond the ones listed, there is a tracking issue for additional elliptic curves, so the set of supported curves is a live discussion rather than a closed list. The repository has no GitHub releases, so the version history lives in the individual crate versions on the registry, each of which is published independently.

Editorial conclusion

RustCrypto elliptic-curves suits a Rust project that needs a specific curve, wants no_std or WebAssembly support, and would rather depend on one small audited crate than a general purpose crypto library. It does not suit a project that wants one dependency covering every curve, because the design is deliberately one crate per curve, and the choice between them is yours to make. Before you pick a crate, check which of the shared building blocks it pulls in, because primefield and primeorder carry most of the code, and note that six crates in the workspace are patched back to local paths, so a release of one crate can depend on unpublished versions of the others.

Frequently asked questions

Official sources

1. Issues
2. README
3. RustCrypto/elliptic-curves on GitHub