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]
Message-ID: <20161128124722.GB2257@gondor.apana.org.au>
Date:   Mon, 28 Nov 2016 20:47:23 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Binoy Jayan <binoy.jayan@...aro.org>
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@...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 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)

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ