kizzycode / crypto_api_chachapoly

This crate implements ChaCha20-IETF, Poly1305 and ChachaPoly-IETF for `crypto_api`

crypto_api_chachapoly

Welcome to crypto_api_chachapoly 🎉

About

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

Security

⚠️ 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:

• ChaCha20 already does this by design
• Poly1305 is based on the public domain Poly1305-Donna implementation (32 bit version) with some ideas from BearSSL (note that this implementation may not be constant time on some older/low end ARM CPUs)
• The AEAD construction is also constant time by design (provided that both underlying algorithms are 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.

Dependencies

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

crypto_api_chachapoly's Issues

AeadCipher::seal_to implementation copies plaintext into output buffer before error checks

The AeadCipher::seal API mutates the provided plaintext buffer to encrypt in-place, after performing various error checks. If the caller ignores the return value (and thus any errors), the plaintext will end up being used unencrypted. This is inherent in the design of the API, so it's a risk that the caller is clearly signing up to.

The AeadCipher::seal_to API provides an interface for interacting with an AEAD that ostensibly encrypts from one buffer into another, according to its documentation:

AEAD-seals plaintext into buf together with ad using key and nonce and returns the ciphertext length

Thus a caller could reasonably assume that if they ignored the return value, the output buffer would be unmodified, and the plaintext would not leak. However, the implementation of AeadCipher::seal_to for ChachaPolyIetf copies the plaintext into the output buffer and then calls AeadCipher::seal internally, breaking this assumption.

This could be addressed by copying the logic from seal into seal_to, so that all error checks are performed first, and the encryption operation is guaranteed to succeed at the time the plaintext is copied into the output buffer.

Originally raised by @daira here.

CHACHAPOLY_MAX is too large by 1 block

In the AEAD construction, block counter = 0 is used to generate the poly1305 key, and encryption of data blocks starts with block counter = 1, so at most 2^32 - 1 blocks can be encrypted. However, the value of CHACHAPOLY_MAX is 2^32 blocks. I believe this means that the code will let you encrypt 2^32*64 bytes, and the last block will be XORed with the poly1305 key, because of n overflowing (at least in release builds).

In addition to fixing the constant I'd recommend adding a check (that works even in release builds) for n overflowing in the xor function.

User of new_sec_key might assume it fills the entire buffer

I can imagine someone misinterpreting new_sec_key's thinking that it fills the entire buffer with random bytes, but it actually only fills the first 32-bytes. To avoid accidental mistakes, I'd recommend changing this line to buf.len() == 32 instead of buf.len() < 32.

(BTW I compared the ChaCha20 and Poly1305 implementations to RFC 8439. I didn't look at the tests. This issue and #2 are the only problems I found).