ChaCha: nonce and counter

[dhardy]

Forking from here. Summary:

• ChaChaRng is for our purposes primarily an RNG; usage as a stream-cipher is secondary
• setting a nonce correctly using set_counter is hard to do correctly due to required byte-to-u64 conversion and Endianness
• we could add another method, e.g. fn set_nonce(&mut self, counter: u64, nonce: [u8; 8])
• we could add other constructors, as in PeterReid's version
• we could just leave as-is and state setting a nonce is unsupported

Current course of action: probably leave as is, with a note that setting a nonce is unsupported.

[pitdicker]

I would like to add one point to the summary:

• We still use the nonce as part of the counter, and not as a constant value. So if you run the RNG long enough, eventually the counter will tick over and increment the nonce, producing 'incorrect' results.

ChaChaRng is for our purposes primarily an RNG; usage as a stream-cipher is secondary

I was relatively unworried when working on the code of ChaCha and others because I was under the impression use as an RNG was the only purpose. Then the only requirements are correctness and performance. Do you really also want to 'advertise' it as useful as a stream-cipher, or should we leave such troubles to a real crypto library? I wouldn't touch it.

If the only purpose is to be used as an RNG, I see no use for a nonce.

[burdges]

We should probably go the "opposite" direction overall, meaning the current behavior of ChaChaRng works fine, but..

We should've eventually abstract stream cipher traits like Peter Reid does and have generic impls of Rng and maybe SeedableRng for them. This is not really rand's problem today, except that requirements on SeedableRng::Seed should be kept minimal.

When should this happen? Imho, there is little point doing anything for RustCrypto right now because that crate depends on GenericArray everywhere, so wait for cosnt type parameters.

Also ChaChaRng should probably not skip any bytes in next_u32 because being cryptographic changes the performance calculations: https://github.com/dhardy/rand/issues/87

[dhardy]

I think ChaChaRng should be first and foremost a random number generator, not a stream cipher. But if other libraries use ChaCha as a "random number generator" we can consider compatibility with them. (It's also possible that this would entail using a wrapper, re-implementing next_u32 around ChaChaRng::fill_bytes, instead of ChaChaRng::next_u32.)

[dhardy]

This was adjusted in: https://github.com/rust-lang-nursery/rand/pull/374 We ultimately decided not to add explicit nonce support.