On Tue, Sep 15, 2020 at 09:50:13PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > On big endian CPUs, the ChaCha20-based CRNG is using the wrong > endianness for the ChaCha20 constants. > > This doesn't matter cryptographically, but technically it means it's not > ChaCha20 anymore. Fix it to always use the standard constants. I'll note that we're not technically ChaCha20 in terms of how we handle the IV. ChaCha20 is defined as having a 96 bit IV and a 32-bit counter. The counter is "usually initialized to be zero or one" (per RFC 7539) and the counter is defined to be Little Endian. We're currently not bothering to deal with Endian conversions with the counter, and we're using a 64-bit counter, instead of a 32-bit counter. We also twiddle 32-bits of the state (crng->state[14]) by XOR'ing it with RDRAND if available at each round, which is also a spec violation. WE also initialize the counter to be a random value, using the input_pool or the primary crng state (if we are initializing the secondary state), but given that the specification says _usually_ zero or one, that's not an out-and-out spec violation. As far as the other deviations / "spec violations" from ChaCha-20 are concerned... I'm "sorry not sorry". :-) I have no objections to changing things so that the first 4 words of the crng state are more ChaCha-20-like, on the theory that most of the cryptoanlysis work (both positive and negative) have been done with the little-endian version of "expand 32-byte k". I don't think it really makes a difference, either positively or negatively. But technically we'd *still* not be using ChaCha20. We could say that we're using the ChaCha20 block function, regardless. Cheers, - Ted
