chacha20: 64-bit counter support

[tarcieri]

The ChaCha20Legacy construction, i.e. the djb variant, is supposed to use a 64-bit counter but currently uses a 32-bit counter because it shares its core implementation with the IETF construction which uses a 32-bit counter.

This results in a counter overflow after generating 256 GiB of keystream. Compatible implementations are able to generate larger keystreams.

I'm not sure how much of a practical concern this actually is, but it did come up in discussions here: rust-random/rand#934 (comment)

We can probably make the counter type generic between u32/u64 in the core implementation if need be.

[nstilt1]

I have some seemingly working code for this, but it builds on the Rng PR with variants.rs. Would you like me to try to adjust it for the current state of chacha20 or wait for the potential merge before opening a PR for it?

[tarcieri]

Let's try to land #333 first

[nstilt1]

I took another look at my 64-bit counter code, and it isn't working correctly on the NEON backend atm.

It uses a const bool in variants.rs to determine which way the counter should be added in the backend, but if there's a better way to do this that doesn't involve modifying the backend code... it might be better. It is currently failing a test shortly after reaching the u32::MAX block pos.

The largest use-case for a 64-bit counter (that I can think of) is file system encryption for mobile devices. I've ran some benches, and chacha20 and even chacha20poly1305 is faster than AES on aarch64. I've benched it on the cloud, on a compute EC2 instance. I would imagine that it's also faster on mobile devices. So... if the 64-bit counter only works for x86 and the software implementation, then there wouldn't really be a point if the main use case is on aarch64.

I will keep working on it a little, but I'd probably prefer a solution that doesn't need to modify the backends, if that's possible. Because the way it is now, every new backend would also need to have specific code for updating the counter

[nstilt1]

On second thought, I feel like more control over a larger nonce would be favorable over having a larger counter

[tarcieri]

@nstilt1 not sure what you mean by that? Are you suggesting making the construction generic over the nonce size rather than a larger counter?

[nstilt1]

@tarcieri I'm suggesting that 64-bit counters are unnecessary, contrary to what I've said previously. I think having 96 bits for a nonce is more practical because it is easier to prevent nonce reuse with finer control over the value. What do you mean about making the construction generic over the nonce size?

[tarcieri]

I wasn't sure what you meant by "more control over a larger nonce".

I agree practically larger counter support probably doesn't matter which is why the current implementation avoided dealing with it. I'm not sure the added complexity is worth it, though it could be considered a compatibility bug with the legacy implementation which is somewhat surprisingly pervasive.