On 8 December 2017 at 10:14, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > Am Freitag, 8. Dezember 2017, 11:06:31 CET schrieb Ard Biesheuvel: > > Hi Ard, > >> >> Given how it is not uncommon for counters to be used as IV, this is a >> fundamental flaw that could rear its head in other places as well, so >> I propose we fix this one way (fix the current code) or the other >> (deprecate the current code and create a new chacha20-rfc7539 >> blockcipher that uses a 96-bit IV and sets the counter to 0) > > Instead of having a complete new implementation of the ChaCha20 cipher, what > about using a specific IV generator for which the kernel crypto API has > already support (see crypto/seqiv.c for example)? > > I.e. we have the current ChaCha20 cipher, but use some "rfc7539iv(chacha20)" > cipher mode where that rfc7539iv is the mentioned IV generator that turns the > given IV (sector number?) into the proper IV for ChaCha20. > To be honest, I don't fully understand how the IV generators work. seqiv is implemented as an AEAD not as a skcipher, and we'd need to wrap chacha20 in something that is usable as a skcipher. In any case, it does make sense to address this by wrapping chacha20 in something generic, rather than having to extend all implementations. -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|