According to an IETF draft,
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring. This enables XChaCha constructions to be stateless, while retaining the same security assumptions as ChaCha.
The small spcnvdr/XChaCha20 library was not small enough, so I re-factored it for minimum footprint. The target processor is 32-bit such as RISC V or Arm Cortex. Giving the code a little-endian dependency simplified it.
The block dependency of spcnvdr/XChaCha20 prevented small chunks of keystream from being used without calling xchacha_init before each xchacha_encrypt_bytes.
This restriction is removed. The small abstraction layer in the form of xc_crypt_setkey and xc_crypt_block facilitate swapping out XChaCha20 with AES or SM4.
More Information
- IETF XChaCha20 Draft
- Bernstein's ChaCha Web page
- Libsodium Documentation
- Crypto++ Documentation
- Wikipedia Salsa20
Test Vectors
In the src folder is a program named test.c It calculates and compares XChaCha20 test vectors obtained from two different sources. The test vectors were borrowed from the IETF draft regarding XChaCha20 and an example from Crypto++ wikipedia. It will compare the output of this XChaCha20 library with known good test vectors to ensure this library is working correctly.
Is it secure?
NIST recommends cryptography such as (e.g., FIPS 140-3, NIST Suite B), or equivalent-strength cryptographic protection, that are expected to be considered cryptographically strong throughout the service life of the device.
XChaCha20 is considered highly secure and may be less susceptible to certain side-channel attacks compared to AES. Google, Cloudflare, and Nordstream use XChaCha20 encryption. In terms of achieving the goals of AES, XChaCha20 is lower-risk because it contains fewer potential surprises.