Unify buffering logic between chacha20, salsa20, and ctr

[tarcieri]

All three of these crates use highly similar (copypasta) buffering logic:

Original ctr code:

• https://github.com/RustCrypto/stream-ciphers/blob/master/ctr/src/lib.rs

Derived chacha20 and salsa20 code:

• https://github.com/RustCrypto/stream-ciphers/blob/master/chacha20/src/cipher.rs
• https://github.com/RustCrypto/stream-ciphers/blob/master/salsa20/src/cipher.rs

The main problem is the ctr is presently specialized to Ctr128 and intended to operate in conjunction with a block cipher, whereas it'd be nice if ChaCha20 and Salsa20 took an integer (32-bit and 64-bit respectively) used to compute the block, but reused the same buffering logic as Ctr128.

ChaCha20 could also benefit from parallel block computation via its AVX2 backend.

[tarcieri]

I guess I'll note one of the main motivations for copying the buffering logic into the chacha20 crate was to make it easier to experiment with different APIs for the block function with the goal of further optimizations.

It'd be good to further optimize chacha20 first before attempting to abstract the buffering logic.

[newpavlov]

It may be also worth to unify with the rand_core::block code. I think ideally we should remove it from rand_core and have a single crate which will be reused for both RNGs and stream ciphers.

cc @dhardy

[dhardy]

I see two different APIs: one with try_apply_keystream and the other with next_u32 / u64 / try_fill_bytes. Is it really worth trying to unify these?

[newpavlov]

For RNGs we may use bit-level counters, so unification probably will not worth the trouble.

[tarcieri]

See also: RustCrypto/traits#336