# RustCrypto block-ciphers: the raw cipher layer and its warnings

> RustCrypto block-ciphers is a collection of block cipher algorithms written in pure Rust, from AES and Camellia to the Russian GOST ciphers and the lightweight Speck and GIFT families. The repository is candid that only the aes crate is constant time and third-party audited, and it tells most users to use the AEAD and MAC crates in sibling repositories instead.

**RustCrypto/block-ciphers** — Collection of block cipher algorithms written in pure Rust

- Repository: https://github.com/RustCrypto/block-ciphers
- Stars: 787 · Forks: 158
- Language: Rust
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/rustcrypto-block-ciphers

## A shelf of ciphers with one warning label

The RustCrypto block-ciphers repository is a collection of block cipher algorithms written in pure Rust, and the README leads with a warning block rather than with a feature list.

The warning says that currently only the aes crate provides a constant-time implementation and has received a third-party security audit. The other crates in the repository are not implemented in a constant-time manner and have not yet received any formal cryptographic and security reviews, and it is generally recommended not to use the other cipher implementations in this repository besides the aes crate. The section ends with USE AT YOUR OWN RISK.

That is an unusual thing to find in a cryptography repository, and it is the single most important fact for an evaluator. Most crate collections in this space are a set of interchangeable primitives with a shared trait, and the differences between them are performance and platform support. Here the difference is a security property, and the repository is explicit about which crate has it.

The badges reinforce the message. There is a HAZMAT badge next to the Apache2/MIT licensed one, and a dependency status badge alongside a Zulip chat link, which is where the community questions would go.

## The cipher trait and why raw ciphers are rarely the goal

The structure of the repository is a lesson in layering. The crates in it implement only raw block cipher functionality, defined by traits in the separate cipher crate, and the README says so in the first line of the higher level constructions section.

The reasoning follows immediately: in practice block ciphers are rarely used in isolation. Instead, they usually play the role of a building block for higher level constructions. In RustCrypto those constructions are implemented generically over block ciphers, in separate repositories.

The four are AEADs, covering GCM, SIV, CCM and MGM, MACs, covering CMAC and PMAC, block modes, covering CTR, CBC and CFB, and key wrapping, covering AES-KW.

The advice at the end of that list is the one to take seriously: most users should use constructions defined in those repositories without directly relying on raw block cipher functionality.

So this repository is a dependency of other libraries rather than a thing you reach for directly, with one exception the README names. That is an important expectation to set, because the crate list looks like a menu of interchangeable ciphers and it is not.

## The catalogue and the two MSRV floors

The supported algorithms table lists twenty one crates, and the naming conventions are worth reading because the crate names do not always match the algorithm names.

The list starts with AES, which the table notes is Rijndael, in the aes crate, and it is the only entry with an MSRV of 1.89. Everything else sits at 1.85, so if you are pinning a toolchain, AES is the one that constrains you. The rest of the table runs through ARIA, the BelT block cipher, Blowfish, Camellia, CAST5 which is CAST-128, CAST6 which is CAST-256, DES and 3DEA in a single des crate, the GIFT family in gift-cipher, IDEA, Kuznyechik and Magma which are the two Russian GOST R 34.12-2015 ciphers, RC2, RC5, RC6, Serpent, SM4, Speck, Threefish, Twofish and XTEA.

The historical spread is a clue about who uses this. Camellia, ARIA, SM4 and the GOST ciphers are the regional standards that show up in hardware and in government interoperability requirements. Speck and GIFT are the lightweight designs for constrained devices. DES, Blowfish, RC2 and IDEA are there for compatibility with existing protocols and legacy data, not because anyone should be choosing them today.

Every crate is published to crates.io with documentation on docs.rs, and the family resemblance to the wider RustCrypto organisation is visible in the crate naming.

## A workspace of twenty one members

The repository is a Cargo workspace, and the Cargo.toml is short enough to read in one go. The workspace uses resolver version 3 and lists its members explicitly, one entry per cipher crate, and the top level directory mirrors that list with a directory per crate.

The one setting that is not the default is in the development profile:

```toml
[profile.dev]
opt-level = 2
```

That is a deliberate choice for a cryptography workspace. Rust compiles debug builds without optimisation by default, and an unoptimised implementation of a block cipher is slow enough to make benchmarks meaningless and fuzzing campaigns impractical. Turning optimisation on for the dev profile keeps the numbers honest without giving up the debug assertions and overflow checks that the dev profile exists for. The setting is scoped to development, so a release build is unaffected.

There is also a Cargo.lock in the tree and a .typos.toml, which is a small detail that says the maintainers run spell checking over the source, and the .github directory carries the workflows.

The last push to the repository was on 2026-10-14, the repository is not archived, and it publishes no GitHub releases, so the crates.io versions are the reference for what is current.

## Choosing a construction instead of a cipher

The most practical advice in the README is the order in which it tells you to think.

Start from the property you need. If you need confidentiality with authentication, that is an AEAD, and the AEADs repository has GCM, SIV, CCM and MGM. If you need an integrity check without secrecy, that is a MAC, and the MACs repository has CMAC and PMAC. If you have a block cipher and need a streaming or chaining mode, the block modes repository has CTR, CBC and CFB. If you need to wrap a key, the key wrapping repository has AES-KW.

Each of those is implemented generically over block ciphers, which is what makes the split sensible: the mode and the cipher are separate choices, so a mode can be tested with a well reviewed cipher, and a cipher can be used with whatever mode the protocol requires.

The one raw cipher in this repository that the README is willing to point you at is aes, and the reason is the combination of constant-time implementation and a third-party security audit. In a world where side channel resistance on a general purpose CPU is hard to guarantee, an implementation that has been reviewed for that property is a different kind of artifact from the rest of the list.

## Where this repository is the wrong choice

Three cases point elsewhere.

The first is anything that protects data today, other than AES used through a reviewed construction. The repository's own words are that the other implementations are not constant time and have had no formal review, and a cipher that leaks through timing is not a cipher for production traffic. If your use case is encryption of user data, the AEAD crates are the destination, and if they need a block cipher under the hood, aes is the one to point them at.

The second is a project that needs a modern, well reviewed Rust crypto stack in general. This repository is a component of a larger organisation, and the components an application actually touches, the AEADs, the MACs, the block modes and the hash functions elsewhere in RustCrypto, are the ones with a broad user base and the audits to match.

The third is a project on a toolchain older than Rust 1.85, since that is the MSRV for everything except aes, and aes needs 1.89. If you are pinned, the choice of crate is made for you before you get to the algorithm question.

On licensing, the crates are available under the Apache License 2.0 or the MIT license at your option, and contributions are dual licensed the same way unless a contributor states otherwise. The repository listing records the licence as one that GitHub cannot categorise, so the LICENSE files in the individual crates are what to check for your own review.

## Conclusion

Adopt the aes crate from this repository if you need a raw block cipher in Rust and can accept the documented constraints, since it is the only implementation here that is constant time and carries a third-party security audit. Do not adopt the other ciphers for new work, because the repository states plainly that they are not constant time and have had no formal cryptographic or security review, and prefer the AEAD, MAC, block mode and key wrapping crates in the sibling repositories for anything that protects data. Verify three things first: which construction you actually need, since raw block ciphers are rarely what you want and the README says most users should not rely on raw block cipher functionality directly; that your threat model needs constant time at all, which is what separates the aes crate from the rest here; and whether the algorithm you need exists in the catalogue, since the workspace lists twenty one members with an MSRV floor of 1.85 for most of them and 1.89 for AES. The crates are dual licensed under Apache-2.0 or MIT at your option, and the last push was on 2026-10-14.

## FAQ

### What is the RustCrypto block-ciphers repository?

It is a collection of block cipher algorithms written in pure Rust, published as separate crates such as aes, aria, camellia, des, sm4, speck-cipher and twofish, and organised as a Cargo workspace with twenty one members.

### Which cipher in this repository is safe to use?

The README states that currently only the aes crate provides a constant-time implementation and has received a third-party security audit, and that it is generally recommended not to use the other cipher implementations in the repository besides the aes crate.

### Do I need a crate from this repository to use an AEAD in Rust?

Not usually. The README says that in RustCrypto, higher level constructions are implemented generically over block ciphers in separate repositories, including AEADs such as GCM, SIV, CCM and MGM, MACs, block modes and key wrapping, and most users should use those constructions rather than relying on raw block cipher functionality directly.

### What Rust version do these crates require?

The table in the README lists an MSRV of 1.89 for the aes crate and 1.85 for the other supported algorithms.

### How are the crates in this repository licensed?

All crates are licensed under either the Apache License 2.0 or the MIT license at your option, and unless a contributor states otherwise, contributions are dual licensed under the same terms.

## Sources

- [Issues](https://github.com/RustCrypto/block-ciphers/issues)
- [README](https://github.com/RustCrypto/block-ciphers/blob/master/README.md)
- [RustCrypto/block-ciphers on GitHub](https://github.com/RustCrypto/block-ciphers)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rustcrypto-block-ciphers