[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHv-k_8_pxWNkypY8uqLG-dsZfHjTdhbSEQNsjqNnStYq4xKTQ@mail.gmail.com>
Date: Wed, 14 Dec 2016 11:39:52 +0530
From: Binoy Jayan <binoy.jayan@...aro.org>
To: Milan Broz <gmazyland@...il.com>
Cc: Oded <oded.golombek@....com>, Ofir <Ofir.Drang@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"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 Milan,
Thank you for the reply.
On 13 December 2016 at 15:31, Milan Broz <gmazyland@...il.com> wrote:
> 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.
Yes, I agree. but the key selection based on sector number restricts the
option of having a larger block size used for encryption.
>> + unsigned int key_size;
>> + unsigned int key_extra_size;
>> + unsigned int key_parts; /* independent parts in key buffer */
>
> ^^^ these key sizes you probably mean by key management.
Yes, I mean splitting the keys into subkeys based on the keycount
parameter (as mentioned below) to the dm-crypt.
cipher[:keycount]-mode-iv:ivopts
aes:2-cbc-essiv:sha256
> It is based on way how the key is currently sent into kernel
> (one hexa string in ioctl that needs to be split) and have to be changed in future.
-Binoy
Powered by blists - more mailing lists