RustCrypto signatures: one crate per signature algorithm

Eight algorithms, eight crates, one workspace

RustCrypto signatures is a Cargo workspace rather than a single library, and the split is by algorithm. The members are dsa, ecdsa, ed25519, ed448, lms, ml-dsa, rfc6979, slh-dsa and xmss, plus an internal bign-genk crate used by the lattice-based implementations. The README presents them in a table that maps each crate to its algorithm, its crates.io page, its documentation on docs.rs and its own build workflow, so every crate is versioned, documented and tested on its own schedule. The repository description narrows the scope to DSA, ECDSA and Ed25519, but the workspace itself has grown to cover the post-quantum and stateful families as well. The last push to the repository was on 2026-10-16, and there are no GitHub releases, so the crates.io version numbers are what you actually pin against.

The signature crate is the contract, not the algorithm

The key architectural decision is stated in one sentence: all algorithms reside in separate crates and are implemented using traits from the signature crate. Functionality across the workspace is expressed in terms of those traits rather than in terms of any one scheme. For an application that only signs and verifies, that means the code that calls the API can stay the same if you move from Ed25519 to ML-DSA, because the shapes it depends on come from the trait definitions rather than from a crate specific helper. It also means the workspace is not a framework with a configuration object and a dispatcher: you pick the crate for the algorithm you need and use the trait API it exposes. That is a smaller thing than some security libraries offer, and it is the reason the crates stay small enough to work without the standard library.

no_std is a design constraint, not a feature toggle

The crates are designed so that they do not require the standard library, and the stated use case is bare-metal or lightweight WebAssembly programming. That constraint reaches into the code, not just the feature flags. The workspace lint configuration turns on warnings for the checks that matter in that environment: std_instead_of_core and std_instead_of_alloc are both set to warn, so a crate that reaches for the standard library where the core crate would do is flagged, and undocumented_unsafe_blocks is set to warn, with unsafe_code forbidden outright at the workspace level under the Rust lints. A crate that must run on a microcontroller with no allocator will need the same discipline, and a project that adopts one of these crates inherits the workspace lint set when it builds from source.

Post-quantum and stateful schemes sit beside Ed25519

The table is more interesting than the description suggests, because the workspace spans three different families. There are the classical curve and finite field schemes, DSA and ECDSA, plus the Edwards curve signatures Ed25519 for Curve25519 and Ed448 for Curve448. There are the hash-based and lattice-based schemes that exist because of quantum computing concerns, Module Lattice DSA citing FIPS 204 and Stateless Hash-Based Signature citing FIPS 205. And there are the stateful hash-based schemes, the Leighton-Micali Signature following RFC 8554 and the eXtended Merkle Signature Scheme following RFC 8391, which carry the requirement of one-time use. The rfc6979 crate is separate again, providing deterministic (EC)DSA signatures as described in RFC 6979, so a DSA or ECDSA user who needs reproducible signatures has a dedicated dependency rather than a feature flag.

What the workspace Cargo.toml says about the project

The root Cargo.toml is short enough to read in full, and it encodes the project's values. The workspace uses resolver 2 and lists its members explicitly:

members = [
    "bign-genk",
    "dsa",
    "ecdsa",
    "ed448",
    "ed25519",
    "lms",
    "ml-dsa",
    "rfc6979",
    "slh-dsa",
    "xmss",
]

Then come the lint tables, where the numeric casts and the unwrap and expect habits are set to warn, documentation and Debug and Copy implementations are required, and unsafe code is forbidden outright:

missing_docs = "warn"
unsafe_code = "forbid"

A development profile with opt-level = 2 shows that the workspace does not accept the unoptimised debug build as a reasonable way to run its own code. The repository also carries .clippy.toml and .typos.toml, plus a SECURITY.md, which is where a security policy for the family lives.

The patch.crates-io block solves a dependency duplication problem

One detail in the root manifest deserves attention because it affects how you consume these crates. There is a global patch for crates-io that points every member crate at its path inside the workspace:

[patch.crates-io]
bign-genk = { path = "./bign-genk" }

The comment in the manifest gives the reason, which is to avoid duplicate dependencies when a member crate is pulled in through git. Without it, a project that depends on one algorithm crate from crates.io and another from a git checkout would end up compiling two copies of shared dependencies. The patch keeps a single version in the build. The repository also carries .gitmodules and a thirdparty/ directory, which is where the submodule-based dependencies live. The practical effect for an adopter is that the workspace is coherent as a whole rather than as nine unrelated libraries, and that mixing a git checkout with a registry dependency does not silently duplicate code.

Licensed Apache-2.0 or MIT, and RSA lives somewhere else

All the crates are licensed under either the Apache License, Version 2.0 or the MIT license, at your option, and the contribution rules say the same thing: unless a contributor states otherwise, a contribution is dual licensed under those terms without additional conditions. That is a permissive pair with no copyleft obligation, which is what makes these crates usable in closed-source products without a discussion with legal counsel about what a signature implementation drags in. The one gap is explicit rather than accidental. RSA signatures are not part of this workspace, and the README points at a separate RustCrypto repository for RSA. The repository's own licence field is not classified by GitHub, so the per-crate licence files are the authoritative source rather than the repository's licence badge.

Where RustCrypto signatures is the wrong choice

There are two clear cases. The first is RSA, which is simply not here, and a system whose peers verify RSA certificates has to look at the other repository or at another implementation entirely. The second is the case where you do not want to hold the private key in your process at all. These crates do the cryptography in your process, which is the right answer for firmware, a build pipeline or a service that owns its keys. If your requirement is that the private key never leaves a hardware module or a managed key service, then the algorithm choice is the least of your problems, and a signing service that holds the key and returns a signature is a different architecture with different failure modes. A third practical case is team velocity. This is a set of low-level crates with trait APIs, no key management, no certificate store and no rotation policy, so a team that wanted a complete signing stack will still have to build most of that layer itself.

Editorial conclusion

RustCrypto signatures fits Rust projects that need public-key signatures on a bare-metal target, in a small WebAssembly build, or in a codebase that wants one audited interface across several algorithms rather than a different library per scheme. It does not fit a project that needs RSA, which the README points at a separate repository, and it does not fit a team that wants a single versioned release train, since the repository publishes no GitHub releases and the crates move on their own cadence on crates.io. Before adopting a crate, check the workspace lint policy you inherit, because unsafe_code is forbidden at the workspace level and that applies to your code too, and confirm that the algorithm you need is present before you design around it.

Frequently asked questions

Official sources

1. Issues
2. README
3. RustCrypto/signatures on GitHub