ChaCha20 counter overflow leading to nonce reuse

[srijs]

Hi!

What's the best place to discuss possible security issues regarding the code in this repo?

(FWIW I'm not sure it's a big issue, but I want to be sure to go through the proper channels :))

[tarcieri]

As a general policy, we should have information on that, and presently don't, which is bad.

That said, I will follow up with you via private email to discuss possible options.

[tarcieri]

I'll go ahead and disclose this issue, saying up front that in my assessment it does not impact users of the chacha20poly1305 crate (main vicarious users of this crate today), which honors the maximum plaintext length (P_MAX) described in RFC 8439 Section 2.8 and therefore should prevent this issue:

https://github.com/RustCrypto/AEADs/blob/master/chacha20poly1305/src/cipher.rs#L55

Anyone using the chacha20 crate directly through the SyncStreamCipher and SyncStreamCipherSeek APIs can potentially overflow the 32-bit counter value, leading to nonce reuse. This would occur after encrypting 2^32 blocks of data (~256GB), or seeking to a point in the keystream where the counter overflows, leading to nonce reuse.

This crate has a chacha20::MAX_BLOCKS constant set to the correct value, however it isn't honored when using the stream-cipher traits.

I'm disclosing in advance with it unpatched because of both the low exploitability and relatively small number of non-chacha20poly1305 usages of this crate.

I will prepare a small fix, do another release, and also file a RustSec issue about it.

[tarcieri]

I just released a stopgap fix for this which panics in chacha20 v0.2.3, and yanked all previous releases of the chacha20 crate.

I opened #70 to track adding a falliable API to salsa20-core to avoid panicking in these situations.