RustCrypto/hashes: twenty-three hash crates on one digest trait

One crate per algorithm, all bound to the digest traits

RustCrypto/hashes is a workspace of separate Rust crates, one per algorithm, and every one of them implements the traits defined in the `digest` crate. A project that needs SHA-2 and nothing else depends on the sha2 crate alone; no other member of the workspace enters that dependency graph. That split is the design, and it is also why the README is short. Usage examples sit in the digest docs and in the individual crate docs, not in this file, so there is nothing to copy from the repository page itself.

Two audiences fit cleanly. The first needs an algorithm already fixed by a standard, a peer, or a legacy format, and can then pick gost94 for GOST R 34.11-94, sm3 for OSCCA GM/T 0004-2012, streebog for GOST R 34.11-2012, ripemd or whirlpool without leaving the trait model. The second builds for bare-metal or WebAssembly, where the standard library is out of reach. A third group is pointed away on purpose: for new applications, or where compatibility with existing standards is not the primary concern, the README directs readers to BLAKE3, SHA-2 or SHA-3.

The security column rates algorithms, not Rust code

Every row of the supported-algorithms table carries a Security rating, and the legend underneath states that the rating describes the algorithm rather than the specific implementation. No known successful attacks earns the green heart. A theoretical break, meaning security lower than claimed, earns yellow. An attack demonstrated in practice earns the broken heart, with the instruction to avoid it if at all possible.

By that reading, md2, md4, md5 and SHA-1 are broken, while gost94, sha1-checked, streebog and tiger are yellow. Here the table contradicts the rule printed under it. SHA-1 and SHA-1 Checked are the same algorithm shipped in two crates, yet one row is broken and the other is yellow. If the column describes algorithms, the two rows should agree. Read the pair as one broken primitive with two package names, and treat the column as a warning about the math rather than a verdict on any given crate.

Where the crates live, and where the first example actually is

There is no install command anywhere in the README, and no dependency line to paste. Each row of the table instead links a crates.io page and a docs.rs page, so the crate is fetched from crates.io under the name shown in the Crate column. That column is worth reading twice. The workspace member for MD5 is md5, while the published package is md-5, so the name you type has to be the crates.io spelling rather than the directory name. The repository root manifest is the only file that shows how the crates are grouped, and it opens like this.

[workspace]
resolver = "3"
members = [
    "sha2",
    "sha3",
]

Three members are shown here out of the full list, which runs from ascon-hash256 through whirlpool. For a first real call, follow the docs.rs link for the specific hash crate, or start with the digest crate docs, where the README says the usage examples live.

Disabling default features is what makes these crates no_std

No crate in the collection requires the Rust standard library. The README attributes this to disabling default crate features, and that switch is what opens bare-metal and WebAssembly use. The root Cargo.toml exposes no crate features at all, so the exact feature names sit in the per-crate manifests and are not visible from the repository root.

Two consequences follow for an adopter. A project on a hosted target keeps the defaults and gets whatever the standard library offers, so moving to no_std is a deliberate per-crate edit rather than a project-wide switch. And a no_std build says nothing at all about whether the primitive itself is current, so the security column still governs the choice. Bare-metal reach and algorithm safety are two separate properties here.

The dev profile builds the hashes at opt-level 2

The root manifest sets `opt-level = 2` under `[profile.dev]`, which is not a Cargo default. An ordinary dev profile compiles dependencies at level 0, so this line raises the floor for every member crate compiled inside that build.

The practical effect lands on profiling rather than on correctness. A timing taken from a debug build of this workspace is already optimized code, and it is not the slow baseline an untouched Cargo profile would give you. The README carries no throughput figures, and the repository has no benchmark harness, so no performance number can be traced back to this project at all. Treat the setting as a build decision with a testing side effect, not as a speed claim.

A patch table redirects sha1 and whirlpool inside the checkout

At the bottom of the same manifest sits a patch table that points two crates at local directories.

[profile.dev]
opt-level = 2

[patch.crates-io]
sha1 = { path = "sha1" }
whirlpool = { path = "whirlpool" }

Inside a checkout, a request for the crates.io sha1 or whirlpool resolves to the code sitting in the sha1/ and whirlpool/ directories instead of the published version. The other twenty-one members are untouched and behave normally. Scope matters here: the redirect applies to builds run against this manifest, so it follows a vendored copy or a manifest you lift into another project, but it does not follow downstream consumers of a crate you publish, since they resolve their own sha1 and whirlpool from crates.io.

No binary, no examples directory, and no benchmark harness

The top-level tree is short and unambiguous: .github/, .gitignore, `.typos.toml`, Cargo.lock, Cargo.toml, README.md and `SECURITY.md`, followed by one directory per algorithm crate. There is no src/ directory at the root, no examples directory, no benchmarks directory and no binary target, so there is nothing here to install and run. The default branch is master rather than main, and a spell checker configuration sits at the root alongside the manifest.

Two details reward a closer look. The crates.io slug for MD5 is md-5 while the workspace member is md5, a mismatch that is unique in the table because every other crate publishes under its directory name; the exclamation marker printed beside that row points at a #crate-names anchor, and the README contains no heading by that name. The repository topic list also includes k12, yet no k12 crate appears in the supported-algorithms table or in the workspace members.

Extendable output and BLAKE3 both live outside this repository

Extendable output functions are absent here by design, and the README sends readers to the RustCrypto/XOFs repository for them. That rules out anyone who assumes SHAKE-style output is already available in these crates.

BLAKE3 is the stranger case. The README tells new users to prefer it above all else, yet the crate implements the same digest traits while being maintained by the BLAKE3 team, and it is not a workspace member, so it never enters this repository's build. As for a comparison with something else, nothing in the table ranks these crates against another Rust implementation, and the README carries no benchmark numbers, so any ranking would be invented. What can be compared is the shape of the choice: depend on the single published crate that matches your standard, or vendor this workspace, where the patch table decides what sha1 and whirlpool resolve to.

Editorial conclusion

Adopt one crate from this collection when a standard, a peer or a legacy format names the algorithm and your toolchain sits at 1.85 or newer. Leave it aside for new protocol design: the README itself steers fresh work toward BLAKE3, SHA-2 or SHA-3, and the BLAKE3 crate is maintained outside this repository. Before adding anything, confirm which algorithm your counterparts exchange digests with, then check the crate name you will actually type, since md5 is published as md-5 on crates.io. Every row in the table also carries an MSRV of 1.85, so one toolchain floor covers the whole collection.

Frequently asked questions

Official sources

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