Ard Biesheuvel [off-list ref] wrote:

As pointed out by Eric [0], the way RFC7539 was interpreted when creating
our implementation of ChaCha20 creates a risk of IV reuse when using a
little endian counter as the IV generator. The reason is that the low end
bits of the counter get mapped onto the ChaCha20 block counter, which
advances every 64 bytes. This means that the counter value that gets
selected as IV for the next input block will collide with the ChaCha20
block counter of the previous block, basically recreating the same
keystream but shifted by 64 bytes.

As Eric pointed out for steram ciphers such as chacha20 our policy
is to expose the raw IV in the base algorithm, and then layer
more restrictive implementations on top that can then be used
in different scenarios such as IPsec or disk encryption.

For example, with CTR, ctr(aes) is the base algorithm and places
no restrictions on the IV, while rfc3686(ctr(aes)) is the more
restrictive version that's used by IPsec.

Within the kernel I don't really see an issue with abuse because
all users are hopefully reviewed by the community.  If you're
worried about incorrect use in user-space we could think about
restricting access to these base implementations.

For chacha20 we did not add a restrictive template because the
primary user IPsec uses it only through AEAD where the IV restriction
is in place.

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt