Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> 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 <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
