summaryrefslogtreecommitdiff
path: root/crypto/jitterentropy.h
diff options
context:
space:
mode:
authorNicolai Stange <nstange@suse.de>2022-02-21 13:10:55 +0100
committerHerbert Xu <herbert@gondor.apana.org.au>2022-03-03 10:47:51 +1200
commit0ed336225f7d1f6fa7ae7c0dbdf951f4afb1238c (patch)
tree2f911a00e94f31847e9c612f284ccfb00a2429cb /crypto/jitterentropy.h
parentbf043120e3de8c052d20fe33eb691d222da20e00 (diff)
downloadlinux-crypto-0ed336225f7d1f6fa7ae7c0dbdf951f4afb1238c.tar.gz
linux-crypto-0ed336225f7d1f6fa7ae7c0dbdf951f4afb1238c.zip
crypto: dh - implement private key generation primitive for ffdheXYZ(dh)
The support for NVME in-band authentication currently in the works ([1]) needs to generate ephemeral DH keys for use with the RFC 7919 safe-prime FFDHE groups. In analogy to ECDH and its ecc_gen_privkey(), implement a dh_safe_prime_gen_privkey() and invoke it from the ffdheXYZ(dh) templates' common ->set_secret(), i.e. dh_safe_prime_set_secret(), in case the input ->key_size is zero. As the RFC 7919 FFDHE groups are classified as approved safe-prime groups by SP800-56Arev3, it's worthwhile to make the new dh_safe_prime_gen_privkey() to follow the approach specified in SP800-56Arev3, sec. 5.6.1.1.3 ("Key-Pair Generation Using Extra Random Bits") in order to achieve conformance. 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. For any safe-prime group Q = (P - 1)/2 by definition and the individual maximum supported security strengths as specified by SP800-56Arev3 have been made available as part of the FFDHE dh_safe_prime definitions introduced with a previous patch. Make dh_safe_prime_gen_privkey() 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 any of the approved safe-prime groups and is also in line with the NVME base spec 2.0, which requires the key size to be >= 256bits. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions