RustCrypto traits: the interfaces the Rust cryptography crates share

Interfaces with no algorithms in them

The RustCrypto traits repository is a collection of traits which describe functionality of cryptographic primitives, and that description is precise enough to be the whole point of the project.

There is not a single algorithm in it. There is no hash function, no cipher, no signature scheme, no key derivation, and no randomness source. What there is, is a set of interfaces, and those interfaces are what let the rest of the Rust cryptography ecosystem be interchangeable.

The reason this matters is the one that every generic programming language struggles with, and that Rust makes explicit. A function that takes a digest needs to know what a digest is. If that is a concrete type, you have one hash function per function signature, and a user who wants a different one cannot have it. If it is a trait, the function is written once and any implementation works, and the choice of algorithm becomes a property of the call site rather than a property of the function.

The split is visible in the repository layout. The top level is a Cargo workspace whose members are the trait crates, one directory per trait, and there is no directory for an algorithm anywhere in the tree.

The project is not archived, the last push was on 2026-10-19, and there are no GitHub releases, which is normal for a set of libraries that are versioned and published through crates.io. The licence metadata in the repository is recorded as unknown, but the README states the terms clearly, and they are the usual dual licence of Apache 2.0 or MIT at your option.

Nine traits for the primitive families

The crate table in the README lists the family, and reading it as a list of what a cryptographic library needs to talk about is instructive.

The aead crate covers authenticated encryption. The cipher crate covers block and stream ciphers. The crypto-common crate holds the common cryptographic traits, the ones that several of the others share, which is where the shared vocabulary lives. The digest crate covers the cryptographic hash function. The elliptic-curve crate covers elliptic curve cryptography. The kem crate covers the key encapsulation mechanism. The password-hash crate covers password hashing. The signature crate covers digital signatures. And the universal-hash crate covers the universal hash function, which is the family used for things like MAC constructions that are not built on a block cipher.

That list is a taxonomy of the primitives rather than of the algorithms, and it maps onto the categories a cryptographic protocol actually needs. You hash with a digest, you encrypt with an AEAD, you sign with a signature, you agree a key with a KEM, you hash a password with the password hashing trait, and you derive keys with the key derivation trait, which has its own directory in the workspace even though it is not in the table of published crates in the excerpt.

The README links each crate name to the Wikipedia page for the algorithm family, which is a small sign of how the project thinks about its own scope: it is describing the category, and the implementations live elsewhere.

Every crate in the table carries the same minimum supported Rust version badge, 1.85, and the additional facade crate, crypto, carries it too. A single MSRV across the family is a deliberate policy, and it is the kind of thing that becomes expensive to fix later, which is why it is worth knowing before you depend on several of them at once.

The facade crate and the patch section

Two entries in the workspace manifest are worth a close look, because they explain how the family is developed and how it is consumed.

The first is the additional crate, crypto, described as a facade for the trait crates. A facade in this sense is a single crate that re-exports the traits you are likely to want together, so that a user does not have to depend on eight separate crates to write a protocol that hashes, encrypts, and signs. It is a convenience layer with no logic of its own, and it is the crate most applications will want rather than the individual ones.

The second is the patch section, which is the one that surprises people who read the manifest.

[patch.crates-io]
crypto-common = { path = "crypto-common" }
digest = { path = "digest" }
signature = { path = "signature" }

A patch section redirects the source of a dependency, and here it redirects three crate names to local paths inside the same repository. That is a development arrangement: when the family is being worked on, the trait crates depend on the local versions of their siblings rather than on the published ones, so a change to a shared trait can be made and tested together with the crates that depend on it.

The practical consequence for a user is that this section matters when you are working inside this repository, and it is something to be aware of when you are not. If you vendor or copy the workspace, or if you build the family from source, the patch section changes where three of your dependencies come from, and removing it silently changes the versions your build resolves.

The workspace also uses the newer resolver, version 3, and the member list includes the key derivation directory alongside the nine published crates.

The lint configuration is the policy

The most revealing part of the manifest is the lint section, because for a cryptography library the lints are not style preferences, they are correctness requirements.

The workspace enables a long list of Clippy lints as warnings. The ones that are about numeric safety are the core of it: casting that loses precision, casting that can truncate, casting that can wrap, casting that changes the sign, and checked conversions, all of them warned. There are also lints against borrowing as a raw pointer, against casting a reference as a pointer, against unnecessary safety comments, and against undocumented unsafe blocks.

That last one is the one that matters most for a cryptographic crate. Undocumented unsafe blocks are exactly where a subtle memory bug would live, and the workspace refuses to let one exist without a comment explaining it.

There is a similar set of Rust lints. Missing documentation is warned, which is why every public item in these crates carries a doc comment. Missing debug implementations and missing copy implementations are warned, so that types in a public API are usable in the ways a user expects. Trivial casts, trivial numeric casts, unused lifetimes, and unused qualifications are all warned.

There are also lints against unwrapping in a Result and against unwrapping at all, against implicit saturating subtraction, against a manual assert, and against a map with unwrap or, and against collecting where iterating would do. Each of those is a small thing, and together they are the difference between a crate where a panic is a deliberate, documented choice and one where it is an accident.

One lint is allowed rather than warned, the needless range loop, which is a pragmatic exception to keep the code idiomatic.

Licence, contribution terms, and where the security policy lives

The licensing arrangement is the standard Rust dual licence, and the contribution clause is written out in full rather than left implicit.

All the crates are licensed under either the Apache License, Version 2.0, or the MIT licence, at your option. The choice is expressed as a dual licence, which means a downstream user picks the one that suits their situation, and the Apache option brings the explicit patent grant that the MIT option does not.

The contribution terms follow the same pattern. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work, as defined in the Apache 2.0 licence, shall be dual licensed as above, without any additional terms or conditions.

That clause is the part worth reading, because it is what determines what happens to code you send to the project. The default is that your contribution inherits the same dual licence, and you can depart from that only by saying so explicitly, which is the mechanism that lets a contributor with a different employment situation or a different set of obligations keep their rights. A project in this position, where the maintainers are careful about the provenance of every line, is a project that expects contributions.

The repository also has a SECURITY.md at the root, which is where a vulnerability report goes, and the small files beside it are worth a glance. There is a typos configuration, which is a spell checker for the source, and a Clippy configuration, which is where the lints that cannot be expressed in the manifest are set.

The whole repository is a Cargo workspace with a lock file, and the chat is a Zulip stream rather than a Discord server or a mailing list, which is a choice some Rust projects make because Zulip is threaded and searchable, and a cryptography project is one where the design discussion is worth being able to find again a year later.

Editorial conclusion

The RustCrypto traits family fits a Rust developer writing a cryptographic implementation, who wants it to plug into the wider ecosystem, or who is writing code that must work with any implementation of a primitive rather than one specific algorithm. It does not fit a developer who just wants to hash a password, because the crates here are interfaces and you will need an implementation crate on top. Verify first that the primitive you need has a trait crate and that the implementation you plan to use implements the version you depend on, that the MSRV of 1.85 matches the toolchain your project is pinned to, and that you understand the patch section in the workspace manifest, which redirects three crate names to local paths for the development of the family itself.

Frequently asked questions

Official sources

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