nx_chacha20.nx

chacha20.nx -- RFC 8439 ChaCha20 stream cipher. license_tier: INDEPENDENT_REDERIVE genealogy_id: international-research-sources/ietf/rfc_8439 256-bit key, 96-bit nonce, 32-bit counter -> 64-byte keystream blocks that XOR with plaintext. Specified in RFC 8439 (May 2018), identical to IETF ChaCha20 (Bernstein 2008, IETF variant by Nir + Langley 2014). Why ChaCha20: - Naturally constant-time: only ADD, ROTATE, XOR operations on 32-bit words. No S-box tables, no branches on secret data. Immune to cache side-channels that plague table-based AES. - Quantum stance: under Grover's algorithm the effective security of a 256-bit-keyed stream cipher is 128 bits -- secure for the forseeable future. Pairs with ML-KEM-768 for TLS 1.3 PQ hybrid. - Simpler than AES (no key schedule distinct from encryption; no bitsliced constant-time variant required). Invariants: CC1 No branches on key, nonce, counter, or state values. Every word of the 16-word state is processed identically. CC2 Rotate-left operations use constant shift amounts (7, 8, 9, 12, 13, 16, 18, 25) -- never driven by secret data. CC3 Memory access pattern depends only on block length, not on key/nonce/counter values. CC4 The 32-bit counter is caller-owned; wrap-around behaviour at 2^32 blocks (= 256 GiB with a given key+nonce) is undefined by the spec. Callers must rekey before wrap. API: chacha20_block(key, counter, nonce, out) -- one 64-byte block chacha20_encrypt(key, counter, nonce, in, n, out) -- full message References: RFC 8439, section 2.3 "The ChaCha20 Block Function" RFC 8439, section 2.4 "The ChaCha20 Encryption Algorithm" Test vectors: RFC 8439 Appendix A.1 / A.2