linux-kernel - Re: [RFC PATCH] crypto: Add IV generation algorithms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Nov 2016 10:15:40 +0530
From:   Binoy Jayan <binoy.jayan@...aro.org>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     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
Subject: Re: [RFC PATCH] crypto: Add IV generation algorithms

On 28 November 2016 at 18:17, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Mon, Nov 21, 2016 at 03:40:09PM +0530, Binoy Jayan wrote:
>> Currently, the iv generation algorithms are implemented in dm-crypt.c.
>> The goal is to move these algorithms from the dm layer to the kernel
>> crypto layer by implementing them as template ciphers so they can be used
>> in relation with algorithms like aes, and with multiple modes like cbc,
>> ecb etc. As part of this patchset, the iv-generation code is moved from the
>> dm layer to the crypto layer. The dm-layer can later be optimized to
>> encrypt larger block sizes in a single call to the crypto engine. The iv
>> generation algorithms implemented in geniv.c includes plain, plain64,
>> essiv, benbi, null, lmk and tcw. These templates are to be configured
>> and has to be invoked as:
>>
>> crypto_alloc_skcipher("plain(cbc(aes))", 0, 0);
>> crypto_alloc_skcipher("essiv(cbc(aes))", 0, 0);
>> ...
>>
>> from the dm layer.
>>
>> Signed-off-by: Binoy Jayan <binoy.jayan@...aro.org>
>
> Thanks a lot for working on this!
>
>> +static int crypto_geniv_set_ctx(struct crypto_skcipher *cipher,
>> +                             void *newctx, unsigned int len)
>> +{
>> +     struct geniv_ctx *ctx = crypto_skcipher_ctx(cipher);
>> +     /*
>> +      * TODO:
>> +      * Do we really need this API or can we append the context
>> +      * 'struct geniv_ctx' to the cipher from dm-crypt and use
>> +      * the same here.
>> +      */
>> +     memcpy(ctx, (char *) newctx, len);
>> +     return geniv_setkey_init_ctx(&ctx->data);
>> +}
>
> I think we should be able to do without adding another API for this.
> Can we instead put the information into the key and/or the IV?
>
> Also it would really help if you could attach a patch for dm-crypt
> that goes along with this (it doesn't have to be complete or
> functional, just showing how this is meant to be used)


Hi Herbert,

Thank you for the reply. The dm-crypt changes are also included as
part of this patchset. It has been tested for functionality as well.
More information can be found in the cover letter including the test
procedure etc.

https://lkml.org/lkml/2016/11/21/168

Thanks,
Binoy