ctcrypt implements RFC 8439 ChaCha20-Poly1305 AEAD from scratch. It is a reference / educational implementation with constant-time intent. It does not try to replace production cryptographic libraries for mission-critical workloads — use libsodium, NSS, BoringSSL, or rustls for that.

If you find a security bug — memory corruption, key-dependent timing, authentication bypass, RFC deviation that weakens cryptographic guarantees — please email the maintainer rather than opening a public issue:

Baurzhan Atynov — bauratynov@gmail.com

Please include:

• description of the issue and impact,
• minimal reproducer (test vector, timing trace, crash input),
• affected commit / version,
• proposed fix if any.

You will get a response within 72 hours. Fixes are prioritised over features.

• Key recovery via arithmetic timing: hot-path operations are uint32_t add / xor / rotate-left only. No table lookups indexed by secrets. No branches conditioned on secret bits.
• Tag forgery via early-exit compare: poly1305_verify uses an OR-accumulator and a single equality test on the accumulator.
• Accidental AAD / ciphertext / tag mismatch: aead_open fails closed, wiping the output buffer on authentication failure.

• Power / EM side channels. Requires hardware-level mitigations outside this code's scope.
• Speculative-execution leaks (Spectre, etc.). Out of scope.
• Fault injection / glitching.
• Key reuse with repeated nonces. This is a caller contract; repeating a (key, nonce) pair under ChaCha20-Poly1305 breaks confidentiality and authenticity.

• CPU timing noise in the timing.c validator on busy hosts.
• Cryptographic opinions unrelated to RFC 8439 (padding flavour, nonce derivation, post-quantum transition).