RustCrypto AEADs: one trait, many authenticated ciphers

A workspace of crates, one directory per algorithm

The repository is a Cargo workspace, and the shape of it is the point. Each algorithm gets its own directory and its own published crate, so a project pulls in exactly one cipher rather than a bundle of everything the maintainers happen to maintain. The workspace Cargo.toml lists the members explicitly:

members = [
    "aead-stream",
    "aes-gcm",
    "aes-gcm-siv",
    "aes-siv",
    "ascon-aead128",
    "belt-dwp",
    "ccm",
    "chacha20poly1305",
    "deoxys",
    "eax",
    "ocb3",
    "xaes-256-gcm",
]

That list covers the AES family in several modes, AES-GCM, AES-GCM-SIV, AES-SIV and XAES-256-GCM, then CCM, EAX, OCB3 and Deoxys-I/II, plus the ChaCha20Poly1305 family, the Ascon-AEAD128 permutation, the BELT-DWP construction from Belarusian standardisation work, and aead-stream for the STREAM construction.

The project documentation describes the collection as Authenticated Encryption with Associated Data algorithms written in pure Rust, and characterises AEADs as high-level symmetric encryption primitives which defend against a wide range of potential attacks, referencing IND-CCA3. Pure Rust here means no C, no OpenSSL binding and no assembly dependency for the primitives themselves.

The audience is Rust developers who already know which construction they need, or who need one specific property such as misuse resistance in AES-GCM-SIV or the associated-data guarantees in AES-SIV.

The aead trait is the contract every crate implements

The functional surface of the whole repository is small. The documentation says that crates functionality is expressed in terms of traits defined in the aead crate, and that is the whole integration story.

One trait, many implementations. If you write code against the trait, you can swap AES-GCM for ChaCha20Poly1305 or for Ascon without touching the call sites, which is what makes the split into separate crates useful rather than merely tidy. The associated data part of the name is the reason the trait exists at all: an AEAD takes a key, a nonce, plaintext, and associated data that is authenticated but not encrypted, and returns ciphertext plus a tag.

That design gives you two properties you have to handle yourself. The associated data is not secret, so it is typically used for a record identifier, a version, or a routing hint, and it is authenticated, so tampering with it makes decryption fail. And the tag is what turns an encryption primitive into an authenticated one, so verification is part of the operation rather than a separate step you might forget.

What the documentation does not spell out is the exact trait method names or the error types. Those live in the documentation for the aead crate on docs.rs, and each algorithm crate links out to its own documentation page. If you are choosing a crate, read the aead trait documentation first, then compare the algorithm crates against your requirements, because the trait is the only stable part of this API surface.

Adding a cipher to a project without dragging in the rest

There is no install script to follow here, and the project documentation does not give one. The way you consume these crates is ordinary Cargo, by naming the algorithm crate you want as a dependency in your own Cargo.toml, and the workspace file shows the exact crate names to use.

Two structural details of the workspace are worth knowing before you wire a crate in. The Cargo.toml carries a patch section pointing crates.io at local paths for two members:

[patch.crates-io]
aead-stream = { path = "aead-stream" }
aes-gcm = { path = "aes-gcm" }

Those entries exist so the workspace can develop and test against the in-tree copies of those two crates, and they are a pattern to copy only if you intend to maintain a fork. A consumer should depend on the published crate names from crates.io and let Cargo resolve the versions.

The other detail is the toolchain floor. The table in the table in the documentation lists an MSRV of 1.85 for every crate in the collection, and the workspace Cargo.toml declares resolver = "3", which is itself a recent edition behaviour. Neither is a problem for a new project on a current toolchain, but both are a problem if you are backporting a cipher into an older build environment, since a 1.85 minimum rules out the older stable releases still common in long-lived enterprise images.

The repository also ships a benches directory and a .cargo directory, so the crates are set up for benchmarking and for cargo configuration.

The lint policy is the real quality signal

RustCrypto's workspace Cargo.toml configures clippy and rustc lints at the workspace level, and the list is unusually strict. Notably, unsafe_code is set to warn, meaning any unsafe block has to be justified and is visible in review. undocumented_unsafe_blocks is warn as well, so a safety comment is required next to any unsafe block, and unnecessary_safety_comment is warn to keep those comments honest rather than cargo-culted.

Several lints force good documentation habits: missing_docs is warn, as are missing_errors_doc and missing_panics_doc, which require that public functions document the errors they return and the conditions under which they panic. There are also must_use_candidate, return_self_not_must_use and missing_copy_implementations, all of which push API decisions toward being explicit rather than implicit.

For an encryption library, the unsafe_code setting is the item to look at. Pure Rust primitives are hard to write correctly, and a workspace that warns on every unsafe block makes those spots findable. Note also that several numeric-cast lints are warn, including cast_possible_truncation and cast_sign_loss, which matters for code that handles lengths and tag sizes.

The clippy configuration also enables extensions for code style and typing, plus a plugin called pylint_strict_informational, and sets jobs = 2 with a conservative default.

Choosing among the modes, and where the choice bites

The collection is broad enough that the real work is picking a member. Each crate corresponds to a specific mode with a specific property, and the linked algorithm references in the documentation point at the underlying specifications.

AES-GCM is the interoperable default, the mode almost every protocol and cloud service already speaks, which is what you want when the ciphertext has to be read by something you do not control. AES-GCM-SIV exists for the opposite case, where nonce misuse would be catastrophic rather than merely bad, which is exactly the situation that arises in multi-server or multi-tenant deployments that generate nonces carelessly. AES-SIV is deterministic authenticated encryption, useful when you need the same plaintext and associated data to produce the same ciphertext, at the cost of leaking equality of plaintexts.

ChaCha20Poly1305, in its X variant, is the choice for software platforms without AES hardware acceleration, and it is what most Rust projects end up with for that reason. CCM and OCB3 are other modes with different performance and security trade-offs. Deoxys and Ascon are candidates from the competition for newer AES replacement, Ascon-AEAD128 being the lightweight permutation family. BELT-DWP follows a Belarusian standard specification. aead-stream implements the STREAM construction, which is about encrypting a long stream rather than a single message.

The honest constraint: choosing well requires you to know what the ciphertext is for. A general purpose choice of AES-GCM is defensible, but a deployment where nonces are generated per message by several machines needs the misuse-resistant mode instead, and no default in this repository makes that choice for you.

Limits, licence and what the repository does not do

This is a collection of AEAD implementations and nothing more. The documentation says as much in one line: crates functionality is expressed in terms of traits defined in the aead crate. There is no hashing crate here, no key derivation, no signature scheme, no password hashing, and no random number generation. A project that reaches for this repository expecting a crypto toolkit will need the sibling RustCrypto projects for the rest, and will end up making a decision about version compatibility across several crates.

The licensing is permissive and unusual in a good way. The documentation states that all crates are licensed under either the Apache License, Version 2.0 or the MIT license at your option, and the contribution section says that unless a contributor states otherwise, a contribution is dual licensed the same way with no additional terms or conditions. The repository metadata itself does not list a licence field, so read the LICENSE files in the individual crate directories if your compliance process needs the exact text for a specific crate.

On maintenance, the repository has no GitHub releases, so crates are published to crates.io and versioned there rather than tagged in this repository. The last push was on 2026-10-13, and there is a SECURITY.md at the root, which is the file to read for how to report a vulnerability in one of these ciphers.

The practical upgrade cost is low for a project that depends on a single crate, and higher for one that has adopted several. With MSRV 1.85 across the board and a workspace lint policy that treats unsafe code and undocumented public items as warnings, a dependency bump can turn into a warning storm in a project that does not enable those lints itself.

Editorial conclusion

RustCrypto AEADs fits a Rust codebase that wants a single authenticated cipher behind a stable trait, or that must support more than one mode such as AES-GCM for interoperability and ChaCha20Poly1305 for software platforms without AES acceleration. It does not fit a project that needs a general purpose crypto toolkit, since this repository covers AEAD constructions only and leaves hashing, key derivation and signing to sibling projects. Before adopting it, read the MSRV column, which is 1.85 for every crate listed, and check that your build environment can meet that floor, because a workspace with a raised toolchain requirement is the most likely upgrade friction you will hit.

Frequently asked questions

Official sources

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