#crypto #poly1305 #aead #cha-cha20 #cha-cha20-poly1305


An implementation of ChaCha20-IETF, Poly1305 and ChachaPoly-IETF for crypto_api

11 releases

0.5.0 Oct 7, 2021
0.4.3 Jul 16, 2020
0.4.2 Dec 9, 2019
0.3.0 Nov 27, 2019
0.1.7 Mar 12, 2019

#73 in Cryptography

Download history 3096/week @ 2021-08-10 2023/week @ 2021-08-17 2649/week @ 2021-08-24 2702/week @ 2021-08-31 2156/week @ 2021-09-07 2556/week @ 2021-09-14 2926/week @ 2021-09-21 2288/week @ 2021-09-28 1536/week @ 2021-10-05 1693/week @ 2021-10-12 1593/week @ 2021-10-19 1265/week @ 2021-10-26 1429/week @ 2021-11-02 875/week @ 2021-11-09 1129/week @ 2021-11-16 1475/week @ 2021-11-23

5,126 downloads per month
Used in 9 crates (3 directly)

BSD-2-Clause OR MIT

872 lines

docs.rs License BSD-2-Clause License MIT crates.io Download numbers AppVeyor CI dependency status


Welcome to crypto_api_chachapoly 🎉


This crate implements the IETF version of ChaCha20, XChaCha20, Poly1305, ChachaPoly-IETF AEAD construction and XChachaPoly.


⚠️ Some words of warning ahead: This library has not been audited yet – use at your own risk! ⚠️

However we try to do things right from the start – this library does not use unsafe Rust, is KISS, tested against various test vectors and uses constant time implementations only.

Test Vectors

All implementations pass all reference test vectors and are assumed to produce correct results even in corner cases. We also use API test vectors (to test input validation) and failure test vectors to test our MAC verification.

Fuzzing Against sodiumoxide

The git repository contains a fuzz-subcrate that generates random inputs and tests if this crate and sodiumoxide produce the same result.

It can be run by cloning the git repo, going into "fuzz/" and running cargo run --release. The crate uses all available CPU threads and stops only if there is an unexpected different result. You can also specify the maximum length if the randomly generated and sized test input; just set TEST_VECTOR_LIMIT as environment variable. If you find an unexpected different result, please copy the entire output and create a new issue on GitHub! 😊

Constant Time Implementations

All implementations are designed to be invulnerable against timing side-channel attacks by performing all secret-dependent computations in constant time:

For more information about constant time implementations, take a look here and here.

Memory Hygiene

crypto_api_chachapoly does not perform any attempts to erase sensitive contents from memory. However all sensitive contents are stored in heap-allocated memory, so if you're using an erasing memory-allocator like MAProper they will be erased nontheless.

Using an erasing memory allocator is a good idea anyway, because Rust makes it pretty hard to keep track on how the memory is managed under the hood – the memory allocator on the other hand sees everything that happens on the heap and can take care of it accordingly.


Because this code implements the crypto_api, it depends on the crypto_api-crate. Otherwise, it's dependency less.