[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHv-k_-EKq2g=Wb+YkPVp9gCXTDEyrxZhQpT5JMSw=WtZ1OC9w@mail.gmail.com>
Date: Thu, 22 Dec 2016 16:25:12 +0530
From: Binoy Jayan <binoy.jayan@...aro.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Milan Broz <gmazyland@...il.com>, Oded <oded.golombek@....com>,
Ofir <Ofir.Drang@....com>,
"David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org, Mark Brown <broonie@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...hat.com>, dm-devel@...hat.com,
Shaohua Li <shli@...nel.org>, linux-raid@...r.kernel.org,
Rajendra <rnayak@...eaurora.org>
Subject: Re: [RFC PATCH v2] crypto: Add IV generation algorithms
Hi Herbert,
On 22 December 2016 at 14:25, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote:
>>
>> By the move everything to cryptoAPI we are basically introducing some strange mix
>> of IV and modes there, I wonder how this is going to be maintained.
>> Anyway, Herbert should say if it is ok...
>
> Well there is precedent in how do the IPsec IV generation. In
> that case the IV generators too are completely specific to that
> application, i.e., IPsec. However, the way structured it allowed
> us to have one single entry path from the IPsec stack into the
> crypto layer regardless of whether you are using AEAD or traditional
> encryption/hashing algorithms.
>
> For IPsec we make the IV generators behave like normal AEAD
> algorithms, except that they take the sequence number as the IV.
>
> The goal here are obviously different. However, by employing
> the same method as we do in IPsec, it appears to me that you
> can effectively process multiple blocks at once instead of having
> to supply one block at a time due to the IV generation issue.
Thank you for clarifying that part.:)
So, I hope we can consider algorithms like lmk and tcw too as IV generation
algorithms, even though they manipulate encrypted data directly?
>> I really do not think the disk encryption key management should be moved
>> outside of dm-crypt. We cannot then change key structure later easily.
I agree with this too, only problem with this is when multiple keys are involved
(where the master key is split into 2 or more), and the key selection is made
with a modular division of the (512-byte) sector number by the number of keys.
> It doesn't have to live outside of dm-crypt. You can register
> these IV generators from there if you really want.
Sorry, but I didn't understand this part.
Thanks,
Binoy
Powered by blists - more mailing lists