Added test vectors for StdRng, verified using rand_chacha.

[dhardy]

Add additional tests from #1642 by @hpenne.

By merging these first we get to run them through CI over rand_chacha and review separately.

CC @tarcieri

[dhardy]

So these are not the test vectors from the paper... thus this is more a stability test than replication.

Do we have a source of ChaCha12 test vectors we can replace these with?

[dhardy]

Potentially this: https://datatracker.ietf.org/doc/html/draft-strombergson-chacha-test-vectors-01

[hpenne]

The ChaCha implemented by rand_chacha and chacha20 is the ChaCha variant from "chacha20-poly1305", defined by that IETF paper for traffic encryption (e.g. TLS). This is not the original ChaCha, but has been modified to reduce the counter from the original 64 bits to 32, to make room for a larger nonce. That was probably OK back then, but now that bandwidths have increased, you may have to rekey frequenctly to avoid counter wraparound (which would completely break the crypto).

The paper for chacha20-poly1305 only has test vectors for ChaCha20 so the expected values have to be replaced, as the comment says. As you correctly point out, this means that the tests only verify stability and are not proof in any way that the algorithm is correct. I am not aware of any official test vectors for a "chacha12-poly1305". There is probably no such algorithm, so there probably are none.

On the other hand, most ChaCha implementations are probably parameterized with regards to number of rounds, so if both these independent(?) implementations (rand_chacha and chacha20) are verified with official test vectors for chacha20-poly1305 and they both pass these tests with these custom expected values for "chacha12-poly1305", then it is a little difficult to imagine how anything can be broken.

The paper with test vectors that you link to is for the original ChaCha algorithm with 64 bit counter. These are the test vectors I used for the ChaCha I implemented for smallrand, as I preferred the original 64 bit counter. They will fail if you use them for the a ChaCha from chacha20-poly1305 like rand_chacha or chacha20.

Speaking of nonces, I think it would improve security a bit if rand initialized the nonce by default. It's good practice to always initialize nonces.

[hpenne]

Hmm. Perhaps some of the Strombergson test vectors could be adapted to work if you pad out the nonce, depending on the endianness of the counter.

[hpenne]

No, I'm in the wrong here. rand_chacha uses the 64 bit counter, while chacha20 does not. So the Strombergson test vectors are better here, and the current test vectors are a little insufficient in that they do not reveal the smaller counter.

[dhardy]

This is not the original ChaCha, but has been modified to reduce the counter from the original 64 bits to 32, to make room for a larger nonce.

Which, as it happens, we don't want for an RNG: we don't need to rekey that frequently, but we do need an RNG that can run all day (or all year) without cycling (because we can't predict how it will be used).

This isn't a concern for here though and RustCrypto/stream-ciphers#399 is already open.

So I think the chacha20 migration is blocked for now unfortunately.