[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0c981ed-2ba2-e884-d2b5-4d4b3fc8c04b@suse.de>
Date: Wed, 1 Dec 2021 08:28:46 +0100
From: Hannes Reinecke <hare@...e.de>
To: Nicolai Stange <nstange@...e.de>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>
Cc: Stephan Müller <smueller@...onox.de>,
Torsten Duwe <duwe@...e.de>, Zaibo Xu <xuzaibo@...wei.com>,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
David Howells <dhowells@...hat.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
qat-linux@...el.com, keyrings@...r.kernel.org
Subject: Re: [PATCH 09/18] crypto: dh - implement private key generation
primitive
On 12/1/21 1:48 AM, Nicolai Stange wrote:
> The support for NVME in-band authentication currently in the works ([1])
> needs to generate ephemeral DH keys.
>
> Implement crypto_dh_gen_privkey() which is intended to be used from
> the DH implementations just in analogy to how ecc_gen_privkey() is used
> for ECDH.
>
> Make the new crypto_dh_gen_privkey() to follow the approach specified
> in SP800-56Arev3, sec. 5.6.1.1.3 ("Key-Pair Generation Using Extra Random
> Bits").
>
> SP800-56Arev3 specifies a lower as well as an upper bound on the generated
> key's length:
> - it must be >= two times the maximum supported security strength of
> the group in question and
> - it must be <= the length of the domain parameter Q.
> Both of these are available only for the safe-prime groups from
> RFC 3526 or RFC 7919, which had been introduced to the kernel with previous
> patches: for any safe-prime group Q = (P - 1)/2 by definition and the
> individual maximum supported security strength as specified by
> SP800-56Arev3 has already been made available alongside the resp. domain
> parameters with said previous patches. Restrict crypto_dh_gen_privkey() to
> these safe-prime groups, i.e. to those groups with any group_id but
> dh_group_id_unknown. Make it pick twice the maximum supported strength
> rounded up to the next power of two for the output key size. This choice
> respects both, the lower and upper bounds given by SP800-90Arev3 for
> all safe-prime groups known to the kernel by now and is also in line with
> the NVME base spec 2.0, which requires the key size to be >= 256bits.
>
> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
>
> Signed-off-by: Nicolai Stange <nstange@...e.de>
> ---
> crypto/Kconfig | 1 +
> crypto/dh_helper.c | 128 ++++++++++++++++++++++++++++++++++++++++++++
> include/crypto/dh.h | 22 ++++++++
> 3 files changed, 151 insertions(+)
>
Reviewed-by: Hannes Reinecke <hare@...e.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Powered by blists - more mailing lists