[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu-5htHxD3gOLWdSNabfiHD=_ssdZLsdksv3FJ_ueK=XEQ@mail.gmail.com>
Date: Fri, 8 Dec 2017 10:27:07 +0000
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Stephan Mueller <smueller@...onox.de>
Cc: Eric Biggers <ebiggers3@...il.com>, linux-fscrypt@...r.kernel.org,
"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
Jaegeuk Kim <jaegeuk@...nel.org>,
Michael Halcrow <mhalcrow@...gle.com>,
Paul Crowley <paulcrowley@...gle.com>,
Martin Willi <martin@...ongswan.org>,
David Gstir <david@...ma-star.at>,
"Jason A . Donenfeld" <Jason@...c4.com>,
Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption
On 8 December 2017 at 10:14, Stephan Mueller <smueller@...onox.de> 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.
Powered by blists - more mailing lists