[PATCH 00/18] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance

[PATCH 00/18] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance

[Nicolai Stange]

Hi all,

first of all, to the people primarily interested in security/keys/, there's
a rather trivial change to security/keys/dh.c in patch 2/18. It would be
great to get ACKs for that...


Hannes' recent work on NVME in-band authentication ([1]) needs access to
the RFC 7919 DH group parameters and also some means to generate ephemeral
keys. He currently implements both as part of his patchset (patches 3/12
and 8/12). After some internal discussion, we decided to split off the bits
needed from crypto/dh into a separate series, i.e. this one here:
 - for the RFC 7919 DH group parameters, it's undesirable from a
   performance POV to serialize the well-known domain parameters via
   crypto_dh_encode_key() just to deserialize them shortly after again,
 - from an architectural POV, it would be preferrable to have the key
   generation code in crypto/dh.c rather than in drivers/nvme/,
   just in analogy to how key generation is supported by crypto/ecdh.c
   already.

Patches 1-13/18 implement all that is needed for the NVME in-band
authentication support. 

Unfortunately, due to the lack of HW, I have not been able to test
the changes to the QAT or HPRE drivers (other than mere compile tests).
Yet I figured it would be a good idea to have them behave consistently with
dh_generic, and so I chose to introduce support for privkey generation to
these as well.


By coincidence, NIST SP800-56Arev3 compliance effectively requires that
the domain parameters are checked against an approved set, which happens
to consists of those safe-prime group parameters specified in RFC 7919,
among others. Thus, introducing the RFC 7919 parameters to the kernel
allows for making the DH implementation to conform to SP800-56Arev3 with
only little effort. I used the opportunity to work crypto/dh towards
SP800-56Arev3 conformance with the rest of this patch series, i.e.
patches 14-18/18. I can split these into another series on its own, if you
like. But as they depend on the earlier patches 1-13/18, I sent them
alongside for now.

This patchset has been tested with and without fips_enabled on x86_64,
ppc64le and s390x, the latter being a big endian machine, which is relevant
for the new test vectors.

Thanks,

Nicolai

[1] https://lkml.kernel.org/r/20211123123801.73197-1-hare@suse.de

Nicolai Stange (18):
  crypto: dh - remove struct dh's ->q member
  crypto: dh - constify struct dh's pointer members
  crypto: dh - optimize domain parameter serialization for well-known
    groups
  crypto: dh - introduce RFC 7919 safe-prime groups
  crypto: testmgr - add DH RFC 7919 ffdhe2048 test vector
  crypto: dh - introduce RFC 3526 safe-prime groups
  crypto: testmgr - add DH RFC 3526 modp2048 test vector
  crypto: testmgr - run only subset of DH vectors based on config
  crypto: dh - implement private key generation primitive
  crypto: dh - introduce support for ephemeral key generation to
    dh-generic
  crypto: dh - introduce support for ephemeral key generation to hpre
    driver
  crypto: dh - introduce support for ephemeral key generation to qat
    driver
  crypto: testmgr - add DH test vectors for key generation
  lib/mpi: export mpi_rshift
  crypto: dh - store group id in dh-generic's dh_ctx
  crypto: dh - calculate Q from P for the full public key verification
  crypto: dh - try to match domain parameters to a known safe-prime
    group
  crypto: dh - accept only approved safe-prime groups in FIPS mode

 crypto/Kconfig                                |  20 +-
 crypto/dh.c                                   |  73 +-
 crypto/dh_helper.c                            | 691 +++++++++++++++++-
 crypto/testmgr.h                              | 342 ++++++++-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c   |  11 +
 drivers/crypto/qat/qat_common/qat_asym_algs.c |   9 +
 include/crypto/dh.h                           |  52 +-
 lib/mpi/mpi-bit.c                             |   1 +
 security/keys/dh.c                            |   2 +-
 9 files changed, 1141 insertions(+), 60 deletions(-)

-- 
2.26.2

[PATCH 01/18] crypto: dh - remove struct dh's ->q member

[Nicolai Stange]

The only current user of the DH KPP algorithm, the
keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q
in struct dh. Remove it and any associated (de)serialization code in
crypto_dh_encode_key() and crypto_dh_decode_key. Adjust the encoded
->secret values in testmgr's DH test vectors accordingly.

Note that the dh-generic implementation would have initialized its
struct dh_ctx's ->q from the decoded struct dh's ->q, if present. If this
struct dh_ctx's ->q would ever have been non-NULL, it would have enabled a
full key validation as specified in NIST SP800-56A in dh_is_pubkey_valid().
However, as outlined above, ->q is always NULL in practice and the full key
validation code is effectively dead. A later patch will make
dh_is_pubkey_valid() to calculate Q from P on the fly, if possible, so
don't remove struct dh_ctx's ->q now, but leave it there until that has
happened.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh.c         |  6 ------
 crypto/dh_helper.c  | 17 ++++-------------
 crypto/testmgr.h    | 16 ++++++----------
 include/crypto/dh.h |  4 ----
 4 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/crypto/dh.c b/crypto/dh.c
index cd4f32092e5c..131b80064cb1 100644
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -59,12 +59,6 @@ static int dh_set_params(struct dh_ctx *ctx, struct dh *params)
 	if (!ctx->p)
 		return -EINVAL;
 
-	if (params->q && params->q_size) {
-		ctx->q = mpi_read_raw_data(params->q, params->q_size);
-		if (!ctx->q)
-			return -EINVAL;
-	}
-
 	ctx->g = mpi_read_raw_data(params->g, params->g_size);
 	if (!ctx->g)
 		return -EINVAL;
diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index 9fd5a42eea15..aabc91e4f63f 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -10,7 +10,7 @@
 #include <crypto/dh.h>
 #include <crypto/kpp.h>
 
-#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 4 * sizeof(int))
+#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 * sizeof(int))
 
 static inline u8 *dh_pack_data(u8 *dst, u8 *end, const void *src, size_t size)
 {
@@ -28,7 +28,7 @@ static inline const u8 *dh_unpack_data(void *dst, const void *src, size_t size)
 
 static inline unsigned int dh_data_size(const struct dh *p)
 {
-	return p->key_size + p->p_size + p->q_size + p->g_size;
+	return p->key_size + p->p_size + p->g_size;
 }
 
 unsigned int crypto_dh_key_len(const struct dh *p)
@@ -53,11 +53,9 @@ int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params)
 	ptr = dh_pack_data(ptr, end, &params->key_size,
 			   sizeof(params->key_size));
 	ptr = dh_pack_data(ptr, end, &params->p_size, sizeof(params->p_size));
-	ptr = dh_pack_data(ptr, end, &params->q_size, sizeof(params->q_size));
 	ptr = dh_pack_data(ptr, end, &params->g_size, sizeof(params->g_size));
 	ptr = dh_pack_data(ptr, end, params->key, params->key_size);
 	ptr = dh_pack_data(ptr, end, params->p, params->p_size);
-	ptr = dh_pack_data(ptr, end, params->q, params->q_size);
 	ptr = dh_pack_data(ptr, end, params->g, params->g_size);
 	if (ptr != end)
 		return -EINVAL;
@@ -79,7 +77,6 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 
 	ptr = dh_unpack_data(&params->key_size, ptr, sizeof(params->key_size));
 	ptr = dh_unpack_data(&params->p_size, ptr, sizeof(params->p_size));
-	ptr = dh_unpack_data(&params->q_size, ptr, sizeof(params->q_size));
 	ptr = dh_unpack_data(&params->g_size, ptr, sizeof(params->g_size));
 	if (secret.len != crypto_dh_key_len(params))
 		return -EINVAL;
@@ -89,7 +86,7 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	 * some drivers assume otherwise.
 	 */
 	if (params->key_size > params->p_size ||
-	    params->g_size > params->p_size || params->q_size > params->p_size)
+	    params->g_size > params->p_size)
 		return -EINVAL;
 
 	/* Don't allocate memory. Set pointers to data within
@@ -97,9 +94,7 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	 */
 	params->key = (void *)ptr;
 	params->p = (void *)(ptr + params->key_size);
-	params->q = (void *)(ptr + params->key_size + params->p_size);
-	params->g = (void *)(ptr + params->key_size + params->p_size +
-			     params->q_size);
+	params->g = (void *)(ptr + params->key_size + params->p_size);
 
 	/*
 	 * Don't permit 'p' to be 0.  It's not a prime number, and it's subject
@@ -109,10 +104,6 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	if (memchr_inv(params->p, 0, params->p_size) == NULL)
 		return -EINVAL;
 
-	/* It is permissible to not provide Q. */
-	if (params->q_size == 0)
-		params->q = NULL;
-
 	return 0;
 }
 EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 779720bf9364..7f7d5ae48721 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1244,17 +1244,15 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.secret =
 #ifdef __LITTLE_ENDIAN
 	"\x01\x00" /* type */
-	"\x15\x02" /* len */
+	"\x11\x02" /* len */
 	"\x00\x01\x00\x00" /* key_size */
 	"\x00\x01\x00\x00" /* p_size */
-	"\x00\x00\x00\x00" /* q_size */
 	"\x01\x00\x00\x00" /* g_size */
 #else
 	"\x00\x01" /* type */
-	"\x02\x15" /* len */
+	"\x02\x11" /* len */
 	"\x00\x00\x01\x00" /* key_size */
 	"\x00\x00\x01\x00" /* p_size */
-	"\x00\x00\x00\x00" /* q_size */
 	"\x00\x00\x00\x01" /* g_size */
 #endif
 	/* xa */
@@ -1344,7 +1342,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	"\xd3\x34\x49\xad\x64\xa6\xb1\xc0\x59\x28\x75\x60\xa7\x8a\xb0\x11"
 	"\x56\x89\x42\x74\x11\xf5\xf6\x5e\x6f\x16\x54\x6a\xb1\x76\x4d\x50"
 	"\x8a\x68\xc1\x5b\x82\xb9\x0d\x00\x32\x50\xed\x88\x87\x48\x92\x17",
-	.secret_size = 533,
+	.secret_size = 529,
 	.b_public_size = 256,
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
@@ -1353,17 +1351,15 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.secret =
 #ifdef __LITTLE_ENDIAN
 	"\x01\x00" /* type */
-	"\x15\x02" /* len */
+	"\x11\x02" /* len */
 	"\x00\x01\x00\x00" /* key_size */
 	"\x00\x01\x00\x00" /* p_size */
-	"\x00\x00\x00\x00" /* q_size */
 	"\x01\x00\x00\x00" /* g_size */
 #else
 	"\x00\x01" /* type */
-	"\x02\x15" /* len */
+	"\x02\x11" /* len */
 	"\x00\x00\x01\x00" /* key_size */
 	"\x00\x00\x01\x00" /* p_size */
-	"\x00\x00\x00\x00" /* q_size */
 	"\x00\x00\x00\x01" /* g_size */
 #endif
 	/* xa */
@@ -1453,7 +1449,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	"\x5e\x5a\x64\xbd\xf6\x85\x04\xe8\x28\x6a\xac\xef\xce\x19\x8e\x9a"
 	"\xfe\x75\xc0\x27\x69\xe3\xb3\x7b\x21\xa7\xb1\x16\xa4\x85\x23\xee"
 	"\xb0\x1b\x04\x6e\xbd\xab\x16\xde\xfd\x86\x6b\xa9\x95\xd7\x0b\xfd",
-	.secret_size = 533,
+	.secret_size = 529,
 	.b_public_size = 256,
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index d71e9858ab86..2585f0e6bb69 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -24,21 +24,17 @@
  *
  * @key:	Private DH key
  * @p:		Diffie-Hellman parameter P
- * @q:		Diffie-Hellman parameter Q
  * @g:		Diffie-Hellman generator G
  * @key_size:	Size of the private DH key
  * @p_size:	Size of DH parameter P
- * @q_size:	Size of DH parameter Q
  * @g_size:	Size of DH generator G
  */
 struct dh {
 	void *key;
 	void *p;
-	void *q;
 	void *g;
 	unsigned int key_size;
 	unsigned int p_size;
-	unsigned int q_size;
 	unsigned int g_size;
 };
 
-- 
2.26.2

Re: [PATCH 01/18] crypto: dh - remove struct dh's ->q member

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> The only current user of the DH KPP algorithm, the
> keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q
> in struct dh. Remove it and any associated (de)serialization code in
> crypto_dh_encode_key() and crypto_dh_decode_key. Adjust the encoded
> ->secret values in testmgr's DH test vectors accordingly.
> 
> Note that the dh-generic implementation would have initialized its
> struct dh_ctx's ->q from the decoded struct dh's ->q, if present. If this
> struct dh_ctx's ->q would ever have been non-NULL, it would have enabled a
> full key validation as specified in NIST SP800-56A in dh_is_pubkey_valid().
> However, as outlined above, ->q is always NULL in practice and the full key
> validation code is effectively dead. A later patch will make
> dh_is_pubkey_valid() to calculate Q from P on the fly, if possible, so
> don't remove struct dh_ctx's ->q now, but leave it there until that has
> happened.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh.c         |  6 ------
>   crypto/dh_helper.c  | 17 ++++-------------
>   crypto/testmgr.h    | 16 ++++++----------
>   include/crypto/dh.h |  4 ----
>   4 files changed, 10 insertions(+), 33 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 02/18] crypto: dh - constify struct dh's pointer members

[Nicolai Stange]

struct dh contains several pointer members corresponding to DH parameters:
->key, ->p and ->g. A subsequent commit will make the struct dh
deserialization function, crypto_dh_decode_key(), to set these to
constant static storage arrays for some of the well-known safe-prime
groups.

Turn the struct dh pointer members' types into "pointer to const" in
preparation for this.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 include/crypto/dh.h | 6 +++---
 security/keys/dh.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 2585f0e6bb69..67f3f6bca527 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -30,9 +30,9 @@
  * @g_size:	Size of DH generator G
  */
 struct dh {
-	void *key;
-	void *p;
-	void *g;
+	const void *key;
+	const void *p;
+	const void *g;
 	unsigned int key_size;
 	unsigned int p_size;
 	unsigned int g_size;
diff --git a/security/keys/dh.c b/security/keys/dh.c
index 1abfa70ed6e1..a58f6fb9f6db 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -14,7 +14,7 @@
 #include <keys/user-type.h>
 #include "internal.h"
 
-static ssize_t dh_data_from_key(key_serial_t keyid, void **data)
+static ssize_t dh_data_from_key(key_serial_t keyid, const void **data)
 {
 	struct key *key;
 	key_ref_t key_ref;
-- 
2.26.2

Re: [PATCH 02/18] crypto: dh - constify struct dh's pointer members

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> struct dh contains several pointer members corresponding to DH parameters:
> ->key, ->p and ->g. A subsequent commit will make the struct dh
> deserialization function, crypto_dh_decode_key(), to set these to
> constant static storage arrays for some of the well-known safe-prime
> groups.
> 
> Turn the struct dh pointer members' types into "pointer to const" in
> preparation for this.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   include/crypto/dh.h | 6 +++---
>   security/keys/dh.c  | 2 +-
>   2 files changed, 4 insertions(+), 4 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 03/18] crypto: dh - optimize domain parameter serialization for well-known groups

[Nicolai Stange]

DH users are supposed to set a struct dh instance's ->p and ->g domain
parameters (as well as the secret ->key), serialize the whole struct dh
instance via the crypto_dh_encode_key() helper and pass the encoded blob
on to the DH's ->set_secret(). All three currently available DH
implementations (generic, drivers/crypto/hisilicon/hpre/ and
drivers/crypto/qat/) would then proceed to call the crypto_dh_decode_key()
helper for unwrapping the encoded struct dh instance again.

Up to now, the only DH user has been the keyctl(KEYCTL_DH_COMPUTE) syscall
and thus, all domain parameters have been coming from userspace. The domain
parameter encoding scheme for DH's ->set_secret() has been a perfectly
reasonable approach in this setting and the potential extra copy of ->p
and ->g during the encoding phase didn't harm much.

However, recently, the need for working with the well-known safe-prime
groups' domain parameters from RFC 3526 and RFC 7919 resp. arose from two
independent developments:
- The NVME in-band authentication support currently being worked on ([1])
  needs to install the RFC 7919 ffdhe groups' domain parameters for DH
  tfms.
- In FIPS mode, there's effectively no sensible way for the DH
  implementation to conform to SP800-56Arev3 other than rejecting any
  parameter set not corresponding to some approved safe-prime group
  specified in either of these two RFCs.

As the ->p arrays' lengths are in the range from 256 to 1024 bytes, it
would be nice if that extra copy during the crypto_dh_encode_key() step
from the NVME in-band authentication code could be avoided. Likewise, it
would be great if the DH implementation's FIPS handling code could avoid
attempting to match the input ->p and ->g against the individual approved
groups' parameters via memcmp() if it's known in advance that the input
corresponds to such one, as is the case for NVME.

Introduce a enum dh_group_id for referring to any of the safe-prime groups
known to the kernel. The introduction of actual such safe-prime groups
alongside with their resp. P and G parameters will be deferred to later
patches. As of now, the new enum contains only a single member,
dh_group_id_unknown, which is meant to be associated with parameter sets
not corresponding to any of the groups known to the kernel, as is needed
to continue to support the current keyctl(KEYCTL_DH_COMPUTE) syscall
semantics.

Add a new 'group_id' member of type enum group_id to struct dh. Make
crypto_dh_encode_key() include it in the serialization and to encode
->p and ->g only if it equals dh_group_id_unknown. For all other possible
values of the encoded ->group_id, the receiving decoding primitive,
crypto_dh_decode_key(), is made to not decode ->p and ->g from the encoded
data, but to look them up in a central registry instead.

The intended usage pattern is that users like NVME wouldn't set any of
the struct dh's ->p or ->g directly, but only the ->group_id for the group
they're interested in. They'd then proceed as usual and call
crypto_dh_encode_key() on the struct dh instance, pass the encoded result
on to DH's ->set_secret() and the latter would then invoke
crypto_dh_decode_key(), which would then in turn lookup the parameters
associated with the passed ->group_id.

Note that this will avoid the extra copy of the ->p and ->g for the groups
(to be made) known to the kernel and also, that a future patch can easily
introduce a validation of ->group_id if in FIPS mode.

As mentioned above, the introduction of actual safe-prime groups will be
deferred to later patches, so for now, only introduce an empty placeholder
array safe_prime_groups[] to be queried by crypto_dh_decode_key() for
domain parameters associated with a given ->group_id as outlined above.
Make its elements to be of the new internal struct safe_prime_group type.
Among the members ->group_id, ->p and ->p_size with obvious meaning, there
will also be a ->max_strength member for storing the maximum security
strength supported by the associated group -- its value will be needed for
the upcoming private key generation support.

Finally, update the encoded secrets provided by the testmgr's DH test
vectors in order to account for the additional ->group_id field expected
by crypto_dh_decode_key() now.

[1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh_helper.c  | 88 +++++++++++++++++++++++++++++++++++----------
 crypto/testmgr.h    | 16 +++++----
 include/crypto/dh.h |  6 ++++
 3 files changed, 86 insertions(+), 24 deletions(-)

diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index aabc91e4f63f..a6c9389d8219 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -10,7 +10,32 @@
 #include <crypto/dh.h>
 #include <crypto/kpp.h>
 
-#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 * sizeof(int))
+#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
+				sizeof(enum dh_group_id) + 3 * sizeof(int))
+
+static const struct safe_prime_group
+{
+	enum dh_group_id group_id;
+	unsigned int max_strength;
+	unsigned int p_size;
+	const char *p;
+} safe_prime_groups[] = {};
+
+/* 2 is used as a generator for all safe-prime groups. */
+static const char safe_prime_group_g[]  = { 2 };
+
+static inline const struct safe_prime_group *
+get_safe_prime_group(enum dh_group_id group_id)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(safe_prime_groups); ++i) {
+		if (safe_prime_groups[i].group_id == group_id)
+			return &safe_prime_groups[i];
+	}
+
+	return NULL;
+}
 
 static inline u8 *dh_pack_data(u8 *dst, u8 *end, const void *src, size_t size)
 {
@@ -28,7 +53,10 @@ static inline const u8 *dh_unpack_data(void *dst, const void *src, size_t size)
 
 static inline unsigned int dh_data_size(const struct dh *p)
 {
-	return p->key_size + p->p_size + p->g_size;
+	if (p->group_id == dh_group_id_unknown)
+		return p->key_size + p->p_size + p->g_size;
+	else
+		return p->key_size;
 }
 
 unsigned int crypto_dh_key_len(const struct dh *p)
@@ -50,13 +78,18 @@ int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params)
 		return -EINVAL;
 
 	ptr = dh_pack_data(ptr, end, &secret, sizeof(secret));
+	ptr = dh_pack_data(ptr, end, &params->group_id,
+			   sizeof(params->group_id));
 	ptr = dh_pack_data(ptr, end, &params->key_size,
 			   sizeof(params->key_size));
 	ptr = dh_pack_data(ptr, end, &params->p_size, sizeof(params->p_size));
 	ptr = dh_pack_data(ptr, end, &params->g_size, sizeof(params->g_size));
 	ptr = dh_pack_data(ptr, end, params->key, params->key_size);
-	ptr = dh_pack_data(ptr, end, params->p, params->p_size);
-	ptr = dh_pack_data(ptr, end, params->g, params->g_size);
+	if (params->group_id == dh_group_id_unknown) {
+		ptr = dh_pack_data(ptr, end, params->p, params->p_size);
+		ptr = dh_pack_data(ptr, end, params->g, params->g_size);
+	}
+
 	if (ptr != end)
 		return -EINVAL;
 	return 0;
@@ -75,12 +108,45 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	if (secret.type != CRYPTO_KPP_SECRET_TYPE_DH)
 		return -EINVAL;
 
+	ptr = dh_unpack_data(&params->group_id, ptr, sizeof(params->group_id));
 	ptr = dh_unpack_data(&params->key_size, ptr, sizeof(params->key_size));
 	ptr = dh_unpack_data(&params->p_size, ptr, sizeof(params->p_size));
 	ptr = dh_unpack_data(&params->g_size, ptr, sizeof(params->g_size));
 	if (secret.len != crypto_dh_key_len(params))
 		return -EINVAL;
 
+	if (params->group_id == dh_group_id_unknown) {
+		/* Don't allocate memory. Set pointers to data within
+		 * the given buffer
+		 */
+		params->key = (void *)ptr;
+		params->p = (void *)(ptr + params->key_size);
+		params->g = (void *)(ptr + params->key_size + params->p_size);
+
+		/*
+		 * Don't permit 'p' to be 0.  It's not a prime number,
+		 * and it's subject to corner cases such as 'mod 0'
+		 * being undefined or crypto_kpp_maxsize() returning
+		 * 0.
+		 */
+		if (memchr_inv(params->p, 0, params->p_size) == NULL)
+			return -EINVAL;
+
+	} else {
+		const struct safe_prime_group *g;
+
+		g = get_safe_prime_group(params->group_id);
+		if (!g)
+			return -EINVAL;
+
+		params->key = (void *)ptr;
+
+		params->p = g->p;
+		params->p_size = g->p_size;
+		params->g = safe_prime_group_g;
+		params->g_size = sizeof(safe_prime_group_g);
+	}
+
 	/*
 	 * Don't permit the buffer for 'key' or 'g' to be larger than 'p', since
 	 * some drivers assume otherwise.
@@ -89,20 +155,6 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	    params->g_size > params->p_size)
 		return -EINVAL;
 
-	/* Don't allocate memory. Set pointers to data within
-	 * the given buffer
-	 */
-	params->key = (void *)ptr;
-	params->p = (void *)(ptr + params->key_size);
-	params->g = (void *)(ptr + params->key_size + params->p_size);
-
-	/*
-	 * Don't permit 'p' to be 0.  It's not a prime number, and it's subject
-	 * to corner cases such as 'mod 0' being undefined or
-	 * crypto_kpp_maxsize() returning 0.
-	 */
-	if (memchr_inv(params->p, 0, params->p_size) == NULL)
-		return -EINVAL;
 
 	return 0;
 }
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 7f7d5ae48721..a8983c8626fa 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1244,13 +1244,15 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.secret =
 #ifdef __LITTLE_ENDIAN
 	"\x01\x00" /* type */
-	"\x11\x02" /* len */
+	"\x15\x02" /* len */
+	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
 	"\x00\x01\x00\x00" /* key_size */
 	"\x00\x01\x00\x00" /* p_size */
 	"\x01\x00\x00\x00" /* g_size */
 #else
 	"\x00\x01" /* type */
-	"\x02\x11" /* len */
+	"\x02\x15" /* len */
+	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
 	"\x00\x00\x01\x00" /* key_size */
 	"\x00\x00\x01\x00" /* p_size */
 	"\x00\x00\x00\x01" /* g_size */
@@ -1342,7 +1344,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	"\xd3\x34\x49\xad\x64\xa6\xb1\xc0\x59\x28\x75\x60\xa7\x8a\xb0\x11"
 	"\x56\x89\x42\x74\x11\xf5\xf6\x5e\x6f\x16\x54\x6a\xb1\x76\x4d\x50"
 	"\x8a\x68\xc1\x5b\x82\xb9\x0d\x00\x32\x50\xed\x88\x87\x48\x92\x17",
-	.secret_size = 529,
+	.secret_size = 533,
 	.b_public_size = 256,
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
@@ -1351,13 +1353,15 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.secret =
 #ifdef __LITTLE_ENDIAN
 	"\x01\x00" /* type */
-	"\x11\x02" /* len */
+	"\x15\x02" /* len */
+	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
 	"\x00\x01\x00\x00" /* key_size */
 	"\x00\x01\x00\x00" /* p_size */
 	"\x01\x00\x00\x00" /* g_size */
 #else
 	"\x00\x01" /* type */
-	"\x02\x11" /* len */
+	"\x02\x15" /* len */
+	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
 	"\x00\x00\x01\x00" /* key_size */
 	"\x00\x00\x01\x00" /* p_size */
 	"\x00\x00\x00\x01" /* g_size */
@@ -1449,7 +1453,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	"\x5e\x5a\x64\xbd\xf6\x85\x04\xe8\x28\x6a\xac\xef\xce\x19\x8e\x9a"
 	"\xfe\x75\xc0\x27\x69\xe3\xb3\x7b\x21\xa7\xb1\x16\xa4\x85\x23\xee"
 	"\xb0\x1b\x04\x6e\xbd\xab\x16\xde\xfd\x86\x6b\xa9\x95\xd7\x0b\xfd",
-	.secret_size = 529,
+	.secret_size = 533,
 	.b_public_size = 256,
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 67f3f6bca527..15d8b2dfe4a2 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -19,6 +19,11 @@
  * the KPP API function call of crypto_kpp_set_secret.
  */
 
+/** enum dh_group_id - identify well-known domain parameter sets */
+enum dh_group_id {
+	dh_group_id_unknown = 0,
+};
+
 /**
  * struct dh - define a DH private key
  *
@@ -30,6 +35,7 @@
  * @g_size:	Size of DH generator G
  */
 struct dh {
+	enum dh_group_id group_id;
 	const void *key;
 	const void *p;
 	const void *g;
-- 
2.26.2

Re: [PATCH 03/18] crypto: dh - optimize domain parameter serialization for well-known groups

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> DH users are supposed to set a struct dh instance's ->p and ->g domain
> parameters (as well as the secret ->key), serialize the whole struct dh
> instance via the crypto_dh_encode_key() helper and pass the encoded blob
> on to the DH's ->set_secret(). All three currently available DH
> implementations (generic, drivers/crypto/hisilicon/hpre/ and
> drivers/crypto/qat/) would then proceed to call the crypto_dh_decode_key()
> helper for unwrapping the encoded struct dh instance again.
> 
> Up to now, the only DH user has been the keyctl(KEYCTL_DH_COMPUTE) syscall
> and thus, all domain parameters have been coming from userspace. The domain
> parameter encoding scheme for DH's ->set_secret() has been a perfectly
> reasonable approach in this setting and the potential extra copy of ->p
> and ->g during the encoding phase didn't harm much.
> 
> However, recently, the need for working with the well-known safe-prime
> groups' domain parameters from RFC 3526 and RFC 7919 resp. arose from two
> independent developments:
> - The NVME in-band authentication support currently being worked on ([1])
>    needs to install the RFC 7919 ffdhe groups' domain parameters for DH
>    tfms.
> - In FIPS mode, there's effectively no sensible way for the DH
>    implementation to conform to SP800-56Arev3 other than rejecting any
>    parameter set not corresponding to some approved safe-prime group
>    specified in either of these two RFCs.
> 
> As the ->p arrays' lengths are in the range from 256 to 1024 bytes, it
> would be nice if that extra copy during the crypto_dh_encode_key() step
> from the NVME in-band authentication code could be avoided. Likewise, it
> would be great if the DH implementation's FIPS handling code could avoid
> attempting to match the input ->p and ->g against the individual approved
> groups' parameters via memcmp() if it's known in advance that the input
> corresponds to such one, as is the case for NVME.
> 
> Introduce a enum dh_group_id for referring to any of the safe-prime groups
> known to the kernel. The introduction of actual such safe-prime groups
> alongside with their resp. P and G parameters will be deferred to later
> patches. As of now, the new enum contains only a single member,
> dh_group_id_unknown, which is meant to be associated with parameter sets
> not corresponding to any of the groups known to the kernel, as is needed
> to continue to support the current keyctl(KEYCTL_DH_COMPUTE) syscall
> semantics.
> 
> Add a new 'group_id' member of type enum group_id to struct dh. Make
> crypto_dh_encode_key() include it in the serialization and to encode
> ->p and ->g only if it equals dh_group_id_unknown. For all other possible
> values of the encoded ->group_id, the receiving decoding primitive,
> crypto_dh_decode_key(), is made to not decode ->p and ->g from the encoded
> data, but to look them up in a central registry instead.
> 
> The intended usage pattern is that users like NVME wouldn't set any of
> the struct dh's ->p or ->g directly, but only the ->group_id for the group
> they're interested in. They'd then proceed as usual and call
> crypto_dh_encode_key() on the struct dh instance, pass the encoded result
> on to DH's ->set_secret() and the latter would then invoke
> crypto_dh_decode_key(), which would then in turn lookup the parameters
> associated with the passed ->group_id.
> 
> Note that this will avoid the extra copy of the ->p and ->g for the groups
> (to be made) known to the kernel and also, that a future patch can easily
> introduce a validation of ->group_id if in FIPS mode.
> 
> As mentioned above, the introduction of actual safe-prime groups will be
> deferred to later patches, so for now, only introduce an empty placeholder
> array safe_prime_groups[] to be queried by crypto_dh_decode_key() for
> domain parameters associated with a given ->group_id as outlined above.
> Make its elements to be of the new internal struct safe_prime_group type.
> Among the members ->group_id, ->p and ->p_size with obvious meaning, there
> will also be a ->max_strength member for storing the maximum security
> strength supported by the associated group -- its value will be needed for
> the upcoming private key generation support.
> 
> Finally, update the encoded secrets provided by the testmgr's DH test
> vectors in order to account for the additional ->group_id field expected
> by crypto_dh_decode_key() now.
> 
> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh_helper.c  | 88 +++++++++++++++++++++++++++++++++++----------
>   crypto/testmgr.h    | 16 +++++----
>   include/crypto/dh.h |  6 ++++
>   3 files changed, 86 insertions(+), 24 deletions(-)
> 
> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
> index aabc91e4f63f..a6c9389d8219 100644
> --- a/crypto/dh_helper.c
> +++ b/crypto/dh_helper.c
> @@ -10,7 +10,32 @@
>   #include <crypto/dh.h>
>   #include <crypto/kpp.h>
>   
> -#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 * sizeof(int))
> +#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
> +				sizeof(enum dh_group_id) + 3 * sizeof(int))

That is not a good practise; 'enum' doesn't have a defined size, and 
will typically default to 'unsigned int'.
But this might well be compiler dependent, so I suggest using a fixes 
size here.

> +
> +static const struct safe_prime_group
> +{
> +	enum dh_group_id group_id;
> +	unsigned int max_strength;
> +	unsigned int p_size;
> +	const char *p;
> +} safe_prime_groups[] = {};
> +
> +/* 2 is used as a generator for all safe-prime groups. */
> +static const char safe_prime_group_g[]  = { 2 };
> +
> +static inline const struct safe_prime_group *
> +get_safe_prime_group(enum dh_group_id group_id)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(safe_prime_groups); ++i) {
> +		if (safe_prime_groups[i].group_id == group_id)
> +			return &safe_prime_groups[i];
> +	}
> +
> +	return NULL;
> +}
>   
>   static inline u8 *dh_pack_data(u8 *dst, u8 *end, const void *src, size_t size)
>   {
> @@ -28,7 +53,10 @@ static inline const u8 *dh_unpack_data(void *dst, const void *src, size_t size)
>   
>   static inline unsigned int dh_data_size(const struct dh *p)
>   {
> -	return p->key_size + p->p_size + p->g_size;
> +	if (p->group_id == dh_group_id_unknown)
> +		return p->key_size + p->p_size + p->g_size;
> +	else
> +		return p->key_size;
>   }
>   
>   unsigned int crypto_dh_key_len(const struct dh *p)
> @@ -50,13 +78,18 @@ int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params)
>   		return -EINVAL;
>   
>   	ptr = dh_pack_data(ptr, end, &secret, sizeof(secret));
> +	ptr = dh_pack_data(ptr, end, &params->group_id,
> +			   sizeof(params->group_id));
>   	ptr = dh_pack_data(ptr, end, &params->key_size,
>   			   sizeof(params->key_size));
>   	ptr = dh_pack_data(ptr, end, &params->p_size, sizeof(params->p_size));
>   	ptr = dh_pack_data(ptr, end, &params->g_size, sizeof(params->g_size));
>   	ptr = dh_pack_data(ptr, end, params->key, params->key_size);
> -	ptr = dh_pack_data(ptr, end, params->p, params->p_size);
> -	ptr = dh_pack_data(ptr, end, params->g, params->g_size);
> +	if (params->group_id == dh_group_id_unknown) {
> +		ptr = dh_pack_data(ptr, end, params->p, params->p_size);
> +		ptr = dh_pack_data(ptr, end, params->g, params->g_size);
> +	}
> +
>   	if (ptr != end)
>   		return -EINVAL;
>   	return 0;
> @@ -75,12 +108,45 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
>   	if (secret.type != CRYPTO_KPP_SECRET_TYPE_DH)
>   		return -EINVAL;
>   
> +	ptr = dh_unpack_data(&params->group_id, ptr, sizeof(params->group_id));
>   	ptr = dh_unpack_data(&params->key_size, ptr, sizeof(params->key_size));
>   	ptr = dh_unpack_data(&params->p_size, ptr, sizeof(params->p_size));
>   	ptr = dh_unpack_data(&params->g_size, ptr, sizeof(params->g_size));
>   	if (secret.len != crypto_dh_key_len(params))
>   		return -EINVAL;
>   
> +	if (params->group_id == dh_group_id_unknown) {
> +		/* Don't allocate memory. Set pointers to data within
> +		 * the given buffer
> +		 */
> +		params->key = (void *)ptr;
> +		params->p = (void *)(ptr + params->key_size);
> +		params->g = (void *)(ptr + params->key_size + params->p_size);
> +
> +		/*
> +		 * Don't permit 'p' to be 0.  It's not a prime number,
> +		 * and it's subject to corner cases such as 'mod 0'
> +		 * being undefined or crypto_kpp_maxsize() returning
> +		 * 0.
> +		 */
> +		if (memchr_inv(params->p, 0, params->p_size) == NULL)
> +			return -EINVAL;
> +
> +	} else {
> +		const struct safe_prime_group *g;
> +
> +		g = get_safe_prime_group(params->group_id);
> +		if (!g)
> +			return -EINVAL;
> +
> +		params->key = (void *)ptr;
> +
> +		params->p = g->p;
> +		params->p_size = g->p_size;
> +		params->g = safe_prime_group_g;
> +		params->g_size = sizeof(safe_prime_group_g);
> +	}
> +
>   	/*
>   	 * Don't permit the buffer for 'key' or 'g' to be larger than 'p', since
>   	 * some drivers assume otherwise.
> @@ -89,20 +155,6 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
>   	    params->g_size > params->p_size)
>   		return -EINVAL;
>   
> -	/* Don't allocate memory. Set pointers to data within
> -	 * the given buffer
> -	 */
> -	params->key = (void *)ptr;
> -	params->p = (void *)(ptr + params->key_size);
> -	params->g = (void *)(ptr + params->key_size + params->p_size);
> -
> -	/*
> -	 * Don't permit 'p' to be 0.  It's not a prime number, and it's subject
> -	 * to corner cases such as 'mod 0' being undefined or
> -	 * crypto_kpp_maxsize() returning 0.
> -	 */
> -	if (memchr_inv(params->p, 0, params->p_size) == NULL)
> -		return -EINVAL;
>   
>   	return 0;
>   }
> diff --git a/crypto/testmgr.h b/crypto/testmgr.h
> index 7f7d5ae48721..a8983c8626fa 100644
> --- a/crypto/testmgr.h
> +++ b/crypto/testmgr.h
> @@ -1244,13 +1244,15 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	.secret =
>   #ifdef __LITTLE_ENDIAN
>   	"\x01\x00" /* type */
> -	"\x11\x02" /* len */
> +	"\x15\x02" /* len */
> +	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
>   	"\x00\x01\x00\x00" /* key_size */
>   	"\x00\x01\x00\x00" /* p_size */
>   	"\x01\x00\x00\x00" /* g_size */
>   #else
>   	"\x00\x01" /* type */
> -	"\x02\x11" /* len */
> +	"\x02\x15" /* len */
> +	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
>   	"\x00\x00\x01\x00" /* key_size */
>   	"\x00\x00\x01\x00" /* p_size */
>   	"\x00\x00\x00\x01" /* g_size */
> @@ -1342,7 +1344,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	"\xd3\x34\x49\xad\x64\xa6\xb1\xc0\x59\x28\x75\x60\xa7\x8a\xb0\x11"
>   	"\x56\x89\x42\x74\x11\xf5\xf6\x5e\x6f\x16\x54\x6a\xb1\x76\x4d\x50"
>   	"\x8a\x68\xc1\x5b\x82\xb9\x0d\x00\x32\x50\xed\x88\x87\x48\x92\x17",
> -	.secret_size = 529,
> +	.secret_size = 533,
>   	.b_public_size = 256,
>   	.expected_a_public_size = 256,
>   	.expected_ss_size = 256,
> @@ -1351,13 +1353,15 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	.secret =
>   #ifdef __LITTLE_ENDIAN
>   	"\x01\x00" /* type */
> -	"\x11\x02" /* len */
> +	"\x15\x02" /* len */
> +	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
>   	"\x00\x01\x00\x00" /* key_size */
>   	"\x00\x01\x00\x00" /* p_size */
>   	"\x01\x00\x00\x00" /* g_size */
>   #else
>   	"\x00\x01" /* type */
> -	"\x02\x11" /* len */
> +	"\x02\x15" /* len */
> +	"\x00\x00\x00\x00" /* group_id == dh_group_id_unknown */
>   	"\x00\x00\x01\x00" /* key_size */
>   	"\x00\x00\x01\x00" /* p_size */
>   	"\x00\x00\x00\x01" /* g_size */
> @@ -1449,7 +1453,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	"\x5e\x5a\x64\xbd\xf6\x85\x04\xe8\x28\x6a\xac\xef\xce\x19\x8e\x9a"
>   	"\xfe\x75\xc0\x27\x69\xe3\xb3\x7b\x21\xa7\xb1\x16\xa4\x85\x23\xee"
>   	"\xb0\x1b\x04\x6e\xbd\xab\x16\xde\xfd\x86\x6b\xa9\x95\xd7\x0b\xfd",
> -	.secret_size = 529,
> +	.secret_size = 533,
>   	.b_public_size = 256,
>   	.expected_a_public_size = 256,
>   	.expected_ss_size = 256,
> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
> index 67f3f6bca527..15d8b2dfe4a2 100644
> --- a/include/crypto/dh.h
> +++ b/include/crypto/dh.h
> @@ -19,6 +19,11 @@
>    * the KPP API function call of crypto_kpp_set_secret.
>    */
>   
> +/** enum dh_group_id - identify well-known domain parameter sets */
> +enum dh_group_id {
> +	dh_group_id_unknown = 0,
> +};
> +

Shouldn't the enum definitions be in uppercase?

>   /**
>    * struct dh - define a DH private key
>    *
> @@ -30,6 +35,7 @@
>    * @g_size:	Size of DH generator G
>    */
>   struct dh {
> +	enum dh_group_id group_id;
>   	const void *key;
>   	const void *p;
>   	const void *g;
> 

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 03/18] crypto: dh - optimize domain parameter serialization for well-known groups

[Nicolai Stange]

Hannes Reinecke <hare@suse.de> writes:

> On 12/1/21 1:48 AM, Nicolai Stange wrote:
>> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
>> index aabc91e4f63f..a6c9389d8219 100644
>> --- a/crypto/dh_helper.c
>> +++ b/crypto/dh_helper.c
>> @@ -10,7 +10,32 @@
>>   #include <crypto/dh.h>
>>   #include <crypto/kpp.h>
>>   -#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 3 *
>> sizeof(int))
>> +#define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
>> +				sizeof(enum dh_group_id) + 3 * sizeof(int))
>
> That is not a good practise; 'enum' doesn't have a defined size, and
> will typically default to 'unsigned int'.
> But this might well be compiler dependent, so I suggest using a fixes
> size here.

Good point, in particular as a certain encoding is assumed for the test
vectors. Changed in v2.

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

[PATCH 04/18] crypto: dh - introduce RFC 7919 safe-prime groups

[Nicolai Stange]

The FFDHE groups specified by RFC 7919 are needed for the current work
on NVME ([1]) and also among the safe-prime groups approved by
SP800-56Arev3. Make them known to the kernel.

More specifically, introduce corresponding members to enum dh_group_id
as well as entries with the resp. domain parameters to the
safe_prime_groups[] array queried by crypto_dh_decode_key(). The resp.
->max_strength value is set to the maximum supported security strength as
specified in SP800-56Arev3.

As the domain parameters consume an substantial amount of space, make
RFC 7919 safe-prime group support selectable by means of the new
CRYPTO_DH_GROUPS_RFC7919 Kconfig option.

[1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/Kconfig      |  11 ++-
 crypto/dh_helper.c  | 219 +++++++++++++++++++++++++++++++++++++++++++-
 include/crypto/dh.h |   7 ++
 3 files changed, 235 insertions(+), 2 deletions(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 285f82647d2b..0f039bbf36e2 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -224,13 +224,22 @@ config CRYPTO_RSA
 	help
 	  Generic implementation of the RSA public key algorithm.
 
-config CRYPTO_DH
+menuconfig CRYPTO_DH
 	tristate "Diffie-Hellman algorithm"
 	select CRYPTO_KPP
 	select MPILIB
 	help
 	  Generic implementation of the Diffie-Hellman algorithm.
 
+if CRYPTO_DH
+config CRYPTO_DH_GROUPS_RFC7919
+	bool "Support for RFC 7919 FFDHE group parameters"
+	help
+	  Enable to allow for the use of RFC 7919 DH parameters in FIPS mode,
+	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
+
+endif
+
 config CRYPTO_ECC
 	tristate
 	select CRYPTO_RNG_DEFAULT
diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index a6c9389d8219..83744c3bfc17 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -19,7 +19,224 @@ static const struct safe_prime_group
 	unsigned int max_strength;
 	unsigned int p_size;
 	const char *p;
-} safe_prime_groups[] = {};
+} safe_prime_groups[] = {
+#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC7919
+	{
+	.group_id = dh_group_id_rfc7919_ffdhe2048,
+	.max_strength = 112,
+	.p_size = 256,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
+	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
+	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
+	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
+	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
+	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
+	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
+	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
+	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
+	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
+	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
+	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
+	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
+	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
+	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
+	"\x88\x6b\x42\x38\x61\x28\x5c\x97\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc7919_ffdhe3072,
+	.max_strength = 128,
+	.p_size = 384,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
+	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
+	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
+	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
+	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
+	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
+	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
+	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
+	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
+	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
+	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
+	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
+	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
+	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
+	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
+	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
+	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
+	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
+	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
+	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
+	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
+	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
+	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
+	"\x25\xe4\x1d\x2b\x66\xc6\x2e\x37\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc7919_ffdhe4096,
+	.max_strength = 152,
+	.p_size = 512,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
+	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
+	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
+	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
+	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
+	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
+	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
+	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
+	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
+	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
+	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
+	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
+	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
+	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
+	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
+	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
+	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
+	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
+	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
+	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
+	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
+	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
+	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
+	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
+	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
+	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
+	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
+	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
+	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
+	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
+	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
+	"\xc6\x8a\x00\x7e\x5e\x65\x5f\x6a\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc7919_ffdhe6144,
+	.max_strength = 176,
+	.p_size = 768,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
+	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
+	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
+	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
+	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
+	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
+	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
+	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
+	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
+	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
+	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
+	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
+	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
+	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
+	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
+	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
+	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
+	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
+	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
+	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
+	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
+	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
+	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
+	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
+	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
+	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
+	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
+	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
+	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
+	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
+	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
+	"\xc6\x8a\x00\x7e\x5e\x0d\xd9\x02\x0b\xfd\x64\xb6\x45\x03\x6c\x7a"
+	"\x4e\x67\x7d\x2c\x38\x53\x2a\x3a\x23\xba\x44\x42\xca\xf5\x3e\xa6"
+	"\x3b\xb4\x54\x32\x9b\x76\x24\xc8\x91\x7b\xdd\x64\xb1\xc0\xfd\x4c"
+	"\xb3\x8e\x8c\x33\x4c\x70\x1c\x3a\xcd\xad\x06\x57\xfc\xcf\xec\x71"
+	"\x9b\x1f\x5c\x3e\x4e\x46\x04\x1f\x38\x81\x47\xfb\x4c\xfd\xb4\x77"
+	"\xa5\x24\x71\xf7\xa9\xa9\x69\x10\xb8\x55\x32\x2e\xdb\x63\x40\xd8"
+	"\xa0\x0e\xf0\x92\x35\x05\x11\xe3\x0a\xbe\xc1\xff\xf9\xe3\xa2\x6e"
+	"\x7f\xb2\x9f\x8c\x18\x30\x23\xc3\x58\x7e\x38\xda\x00\x77\xd9\xb4"
+	"\x76\x3e\x4e\x4b\x94\xb2\xbb\xc1\x94\xc6\x65\x1e\x77\xca\xf9\x92"
+	"\xee\xaa\xc0\x23\x2a\x28\x1b\xf6\xb3\xa7\x39\xc1\x22\x61\x16\x82"
+	"\x0a\xe8\xdb\x58\x47\xa6\x7c\xbe\xf9\xc9\x09\x1b\x46\x2d\x53\x8c"
+	"\xd7\x2b\x03\x74\x6a\xe7\x7f\x5e\x62\x29\x2c\x31\x15\x62\xa8\x46"
+	"\x50\x5d\xc8\x2d\xb8\x54\x33\x8a\xe4\x9f\x52\x35\xc9\x5b\x91\x17"
+	"\x8c\xcf\x2d\xd5\xca\xce\xf4\x03\xec\x9d\x18\x10\xc6\x27\x2b\x04"
+	"\x5b\x3b\x71\xf9\xdc\x6b\x80\xd6\x3f\xdd\x4a\x8e\x9a\xdb\x1e\x69"
+	"\x62\xa6\x95\x26\xd4\x31\x61\xc1\xa4\x1d\x57\x0d\x79\x38\xda\xd4"
+	"\xa4\x0e\x32\x9c\xd0\xe4\x0e\x65\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc7919_ffdhe8192,
+	.max_strength = 200,
+	.p_size = 1024,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
+	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
+	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
+	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
+	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
+	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
+	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
+	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
+	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
+	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
+	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
+	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
+	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
+	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
+	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
+	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
+	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
+	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
+	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
+	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
+	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
+	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
+	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
+	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
+	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
+	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
+	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
+	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
+	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
+	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
+	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
+	"\xc6\x8a\x00\x7e\x5e\x0d\xd9\x02\x0b\xfd\x64\xb6\x45\x03\x6c\x7a"
+	"\x4e\x67\x7d\x2c\x38\x53\x2a\x3a\x23\xba\x44\x42\xca\xf5\x3e\xa6"
+	"\x3b\xb4\x54\x32\x9b\x76\x24\xc8\x91\x7b\xdd\x64\xb1\xc0\xfd\x4c"
+	"\xb3\x8e\x8c\x33\x4c\x70\x1c\x3a\xcd\xad\x06\x57\xfc\xcf\xec\x71"
+	"\x9b\x1f\x5c\x3e\x4e\x46\x04\x1f\x38\x81\x47\xfb\x4c\xfd\xb4\x77"
+	"\xa5\x24\x71\xf7\xa9\xa9\x69\x10\xb8\x55\x32\x2e\xdb\x63\x40\xd8"
+	"\xa0\x0e\xf0\x92\x35\x05\x11\xe3\x0a\xbe\xc1\xff\xf9\xe3\xa2\x6e"
+	"\x7f\xb2\x9f\x8c\x18\x30\x23\xc3\x58\x7e\x38\xda\x00\x77\xd9\xb4"
+	"\x76\x3e\x4e\x4b\x94\xb2\xbb\xc1\x94\xc6\x65\x1e\x77\xca\xf9\x92"
+	"\xee\xaa\xc0\x23\x2a\x28\x1b\xf6\xb3\xa7\x39\xc1\x22\x61\x16\x82"
+	"\x0a\xe8\xdb\x58\x47\xa6\x7c\xbe\xf9\xc9\x09\x1b\x46\x2d\x53\x8c"
+	"\xd7\x2b\x03\x74\x6a\xe7\x7f\x5e\x62\x29\x2c\x31\x15\x62\xa8\x46"
+	"\x50\x5d\xc8\x2d\xb8\x54\x33\x8a\xe4\x9f\x52\x35\xc9\x5b\x91\x17"
+	"\x8c\xcf\x2d\xd5\xca\xce\xf4\x03\xec\x9d\x18\x10\xc6\x27\x2b\x04"
+	"\x5b\x3b\x71\xf9\xdc\x6b\x80\xd6\x3f\xdd\x4a\x8e\x9a\xdb\x1e\x69"
+	"\x62\xa6\x95\x26\xd4\x31\x61\xc1\xa4\x1d\x57\x0d\x79\x38\xda\xd4"
+	"\xa4\x0e\x32\x9c\xcf\xf4\x6a\xaa\x36\xad\x00\x4c\xf6\x00\xc8\x38"
+	"\x1e\x42\x5a\x31\xd9\x51\xae\x64\xfd\xb2\x3f\xce\xc9\x50\x9d\x43"
+	"\x68\x7f\xeb\x69\xed\xd1\xcc\x5e\x0b\x8c\xc3\xbd\xf6\x4b\x10\xef"
+	"\x86\xb6\x31\x42\xa3\xab\x88\x29\x55\x5b\x2f\x74\x7c\x93\x26\x65"
+	"\xcb\x2c\x0f\x1c\xc0\x1b\xd7\x02\x29\x38\x88\x39\xd2\xaf\x05\xe4"
+	"\x54\x50\x4a\xc7\x8b\x75\x82\x82\x28\x46\xc0\xba\x35\xc3\x5f\x5c"
+	"\x59\x16\x0c\xc0\x46\xfd\x82\x51\x54\x1f\xc6\x8c\x9c\x86\xb0\x22"
+	"\xbb\x70\x99\x87\x6a\x46\x0e\x74\x51\xa8\xa9\x31\x09\x70\x3f\xee"
+	"\x1c\x21\x7e\x6c\x38\x26\xe5\x2c\x51\xaa\x69\x1e\x0e\x42\x3c\xfc"
+	"\x99\xe9\xe3\x16\x50\xc1\x21\x7b\x62\x48\x16\xcd\xad\x9a\x95\xf9"
+	"\xd5\xb8\x01\x94\x88\xd9\xc0\xa0\xa1\xfe\x30\x75\xa5\x77\xe2\x31"
+	"\x83\xf8\x1d\x4a\x3f\x2f\xa4\x57\x1e\xfc\x8c\xe0\xba\x8a\x4f\xe8"
+	"\xb6\x85\x5d\xfe\x72\xb0\xa6\x6e\xde\xd2\xfb\xab\xfb\xe5\x8a\x30"
+	"\xfa\xfa\xbe\x1c\x5d\x71\xa8\x7e\x2f\x74\x1e\xf8\xc1\xfe\x86\xfe"
+	"\xa6\xbb\xfd\xe5\x30\x67\x7f\x0d\x97\xd1\x1d\x49\xf7\xa8\x44\x3d"
+	"\x08\x22\xe5\x06\xa9\xf4\x61\x4e\x01\x1e\x2a\x94\x83\x8f\xf8\x8c"
+	"\xd6\x8c\x8b\xb7\xc5\xc6\x42\x4c\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+#endif /* CONFIG_CRYPTO_DH_GROUPS_RFC7919 */
+};
 
 /* 2 is used as a generator for all safe-prime groups. */
 static const char safe_prime_group_g[]  = { 2 };
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 15d8b2dfe4a2..59be1fe3a978 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -22,6 +22,13 @@
 /** enum dh_group_id - identify well-known domain parameter sets */
 enum dh_group_id {
 	dh_group_id_unknown = 0,
+#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC7919
+	dh_group_id_rfc7919_ffdhe2048 = 1, /* Constant used by test vector. */
+	dh_group_id_rfc7919_ffdhe3072,
+	dh_group_id_rfc7919_ffdhe4096,
+	dh_group_id_rfc7919_ffdhe6144,
+	dh_group_id_rfc7919_ffdhe8192,
+#endif
 };
 
 /**
-- 
2.26.2

Re: [PATCH 04/18] crypto: dh - introduce RFC 7919 safe-prime groups

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> The FFDHE groups specified by RFC 7919 are needed for the current work
> on NVME ([1]) and also among the safe-prime groups approved by
> SP800-56Arev3. Make them known to the kernel.
> 
> More specifically, introduce corresponding members to enum dh_group_id
> as well as entries with the resp. domain parameters to the
> safe_prime_groups[] array queried by crypto_dh_decode_key(). The resp.
> ->max_strength value is set to the maximum supported security strength as
> specified in SP800-56Arev3.
> 
> As the domain parameters consume an substantial amount of space, make
> RFC 7919 safe-prime group support selectable by means of the new
> CRYPTO_DH_GROUPS_RFC7919 Kconfig option.
> 
> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/Kconfig      |  11 ++-
>   crypto/dh_helper.c  | 219 +++++++++++++++++++++++++++++++++++++++++++-
>   include/crypto/dh.h |   7 ++
>   3 files changed, 235 insertions(+), 2 deletions(-)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 285f82647d2b..0f039bbf36e2 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -224,13 +224,22 @@ config CRYPTO_RSA
>   	help
>   	  Generic implementation of the RSA public key algorithm.
>   
> -config CRYPTO_DH
> +menuconfig CRYPTO_DH
>   	tristate "Diffie-Hellman algorithm"
>   	select CRYPTO_KPP
>   	select MPILIB
>   	help
>   	  Generic implementation of the Diffie-Hellman algorithm.
>   
> +if CRYPTO_DH
> +config CRYPTO_DH_GROUPS_RFC7919
> +	bool "Support for RFC 7919 FFDHE group parameters"
> +	help
> +	  Enable to allow for the use of RFC 7919 DH parameters in FIPS mode,
> +	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
> +
> +endif
> +
>   config CRYPTO_ECC
>   	tristate
>   	select CRYPTO_RNG_DEFAULT
> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
> index a6c9389d8219..83744c3bfc17 100644
> --- a/crypto/dh_helper.c
> +++ b/crypto/dh_helper.c
> @@ -19,7 +19,224 @@ static const struct safe_prime_group
>   	unsigned int max_strength;
>   	unsigned int p_size;
>   	const char *p;
> -} safe_prime_groups[] = {};
> +} safe_prime_groups[] = {
> +#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC7919
> +	{
> +	.group_id = dh_group_id_rfc7919_ffdhe2048,
> +	.max_strength = 112,
> +	.p_size = 256,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
> +	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
> +	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
> +	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
> +	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
> +	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
> +	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
> +	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
> +	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
> +	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
> +	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
> +	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
> +	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
> +	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
> +	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
> +	"\x88\x6b\x42\x38\x61\x28\x5c\x97\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc7919_ffdhe3072,
> +	.max_strength = 128,
> +	.p_size = 384,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
> +	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
> +	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
> +	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
> +	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
> +	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
> +	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
> +	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
> +	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
> +	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
> +	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
> +	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
> +	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
> +	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
> +	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
> +	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
> +	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
> +	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
> +	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
> +	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
> +	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
> +	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
> +	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
> +	"\x25\xe4\x1d\x2b\x66\xc6\x2e\x37\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc7919_ffdhe4096,
> +	.max_strength = 152,
> +	.p_size = 512,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
> +	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
> +	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
> +	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
> +	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
> +	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
> +	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
> +	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
> +	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
> +	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
> +	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
> +	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
> +	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
> +	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
> +	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
> +	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
> +	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
> +	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
> +	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
> +	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
> +	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
> +	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
> +	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
> +	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
> +	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
> +	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
> +	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
> +	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
> +	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
> +	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
> +	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
> +	"\xc6\x8a\x00\x7e\x5e\x65\x5f\x6a\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc7919_ffdhe6144,
> +	.max_strength = 176,
> +	.p_size = 768,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
> +	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
> +	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
> +	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
> +	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
> +	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
> +	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
> +	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
> +	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
> +	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
> +	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
> +	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
> +	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
> +	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
> +	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
> +	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
> +	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
> +	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
> +	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
> +	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
> +	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
> +	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
> +	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
> +	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
> +	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
> +	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
> +	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
> +	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
> +	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
> +	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
> +	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
> +	"\xc6\x8a\x00\x7e\x5e\x0d\xd9\x02\x0b\xfd\x64\xb6\x45\x03\x6c\x7a"
> +	"\x4e\x67\x7d\x2c\x38\x53\x2a\x3a\x23\xba\x44\x42\xca\xf5\x3e\xa6"
> +	"\x3b\xb4\x54\x32\x9b\x76\x24\xc8\x91\x7b\xdd\x64\xb1\xc0\xfd\x4c"
> +	"\xb3\x8e\x8c\x33\x4c\x70\x1c\x3a\xcd\xad\x06\x57\xfc\xcf\xec\x71"
> +	"\x9b\x1f\x5c\x3e\x4e\x46\x04\x1f\x38\x81\x47\xfb\x4c\xfd\xb4\x77"
> +	"\xa5\x24\x71\xf7\xa9\xa9\x69\x10\xb8\x55\x32\x2e\xdb\x63\x40\xd8"
> +	"\xa0\x0e\xf0\x92\x35\x05\x11\xe3\x0a\xbe\xc1\xff\xf9\xe3\xa2\x6e"
> +	"\x7f\xb2\x9f\x8c\x18\x30\x23\xc3\x58\x7e\x38\xda\x00\x77\xd9\xb4"
> +	"\x76\x3e\x4e\x4b\x94\xb2\xbb\xc1\x94\xc6\x65\x1e\x77\xca\xf9\x92"
> +	"\xee\xaa\xc0\x23\x2a\x28\x1b\xf6\xb3\xa7\x39\xc1\x22\x61\x16\x82"
> +	"\x0a\xe8\xdb\x58\x47\xa6\x7c\xbe\xf9\xc9\x09\x1b\x46\x2d\x53\x8c"
> +	"\xd7\x2b\x03\x74\x6a\xe7\x7f\x5e\x62\x29\x2c\x31\x15\x62\xa8\x46"
> +	"\x50\x5d\xc8\x2d\xb8\x54\x33\x8a\xe4\x9f\x52\x35\xc9\x5b\x91\x17"
> +	"\x8c\xcf\x2d\xd5\xca\xce\xf4\x03\xec\x9d\x18\x10\xc6\x27\x2b\x04"
> +	"\x5b\x3b\x71\xf9\xdc\x6b\x80\xd6\x3f\xdd\x4a\x8e\x9a\xdb\x1e\x69"
> +	"\x62\xa6\x95\x26\xd4\x31\x61\xc1\xa4\x1d\x57\x0d\x79\x38\xda\xd4"
> +	"\xa4\x0e\x32\x9c\xd0\xe4\x0e\x65\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc7919_ffdhe8192,
> +	.max_strength = 200,
> +	.p_size = 1024,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xad\xf8\x54\x58\xa2\xbb\x4a\x9a"
> +	"\xaf\xdc\x56\x20\x27\x3d\x3c\xf1\xd8\xb9\xc5\x83\xce\x2d\x36\x95"
> +	"\xa9\xe1\x36\x41\x14\x64\x33\xfb\xcc\x93\x9d\xce\x24\x9b\x3e\xf9"
> +	"\x7d\x2f\xe3\x63\x63\x0c\x75\xd8\xf6\x81\xb2\x02\xae\xc4\x61\x7a"
> +	"\xd3\xdf\x1e\xd5\xd5\xfd\x65\x61\x24\x33\xf5\x1f\x5f\x06\x6e\xd0"
> +	"\x85\x63\x65\x55\x3d\xed\x1a\xf3\xb5\x57\x13\x5e\x7f\x57\xc9\x35"
> +	"\x98\x4f\x0c\x70\xe0\xe6\x8b\x77\xe2\xa6\x89\xda\xf3\xef\xe8\x72"
> +	"\x1d\xf1\x58\xa1\x36\xad\xe7\x35\x30\xac\xca\x4f\x48\x3a\x79\x7a"
> +	"\xbc\x0a\xb1\x82\xb3\x24\xfb\x61\xd1\x08\xa9\x4b\xb2\xc8\xe3\xfb"
> +	"\xb9\x6a\xda\xb7\x60\xd7\xf4\x68\x1d\x4f\x42\xa3\xde\x39\x4d\xf4"
> +	"\xae\x56\xed\xe7\x63\x72\xbb\x19\x0b\x07\xa7\xc8\xee\x0a\x6d\x70"
> +	"\x9e\x02\xfc\xe1\xcd\xf7\xe2\xec\xc0\x34\x04\xcd\x28\x34\x2f\x61"
> +	"\x91\x72\xfe\x9c\xe9\x85\x83\xff\x8e\x4f\x12\x32\xee\xf2\x81\x83"
> +	"\xc3\xfe\x3b\x1b\x4c\x6f\xad\x73\x3b\xb5\xfc\xbc\x2e\xc2\x20\x05"
> +	"\xc5\x8e\xf1\x83\x7d\x16\x83\xb2\xc6\xf3\x4a\x26\xc1\xb2\xef\xfa"
> +	"\x88\x6b\x42\x38\x61\x1f\xcf\xdc\xde\x35\x5b\x3b\x65\x19\x03\x5b"
> +	"\xbc\x34\xf4\xde\xf9\x9c\x02\x38\x61\xb4\x6f\xc9\xd6\xe6\xc9\x07"
> +	"\x7a\xd9\x1d\x26\x91\xf7\xf7\xee\x59\x8c\xb0\xfa\xc1\x86\xd9\x1c"
> +	"\xae\xfe\x13\x09\x85\x13\x92\x70\xb4\x13\x0c\x93\xbc\x43\x79\x44"
> +	"\xf4\xfd\x44\x52\xe2\xd7\x4d\xd3\x64\xf2\xe2\x1e\x71\xf5\x4b\xff"
> +	"\x5c\xae\x82\xab\x9c\x9d\xf6\x9e\xe8\x6d\x2b\xc5\x22\x36\x3a\x0d"
> +	"\xab\xc5\x21\x97\x9b\x0d\xea\xda\x1d\xbf\x9a\x42\xd5\xc4\x48\x4e"
> +	"\x0a\xbc\xd0\x6b\xfa\x53\xdd\xef\x3c\x1b\x20\xee\x3f\xd5\x9d\x7c"
> +	"\x25\xe4\x1d\x2b\x66\x9e\x1e\xf1\x6e\x6f\x52\xc3\x16\x4d\xf4\xfb"
> +	"\x79\x30\xe9\xe4\xe5\x88\x57\xb6\xac\x7d\x5f\x42\xd6\x9f\x6d\x18"
> +	"\x77\x63\xcf\x1d\x55\x03\x40\x04\x87\xf5\x5b\xa5\x7e\x31\xcc\x7a"
> +	"\x71\x35\xc8\x86\xef\xb4\x31\x8a\xed\x6a\x1e\x01\x2d\x9e\x68\x32"
> +	"\xa9\x07\x60\x0a\x91\x81\x30\xc4\x6d\xc7\x78\xf9\x71\xad\x00\x38"
> +	"\x09\x29\x99\xa3\x33\xcb\x8b\x7a\x1a\x1d\xb9\x3d\x71\x40\x00\x3c"
> +	"\x2a\x4e\xce\xa9\xf9\x8d\x0a\xcc\x0a\x82\x91\xcd\xce\xc9\x7d\xcf"
> +	"\x8e\xc9\xb5\x5a\x7f\x88\xa4\x6b\x4d\xb5\xa8\x51\xf4\x41\x82\xe1"
> +	"\xc6\x8a\x00\x7e\x5e\x0d\xd9\x02\x0b\xfd\x64\xb6\x45\x03\x6c\x7a"
> +	"\x4e\x67\x7d\x2c\x38\x53\x2a\x3a\x23\xba\x44\x42\xca\xf5\x3e\xa6"
> +	"\x3b\xb4\x54\x32\x9b\x76\x24\xc8\x91\x7b\xdd\x64\xb1\xc0\xfd\x4c"
> +	"\xb3\x8e\x8c\x33\x4c\x70\x1c\x3a\xcd\xad\x06\x57\xfc\xcf\xec\x71"
> +	"\x9b\x1f\x5c\x3e\x4e\x46\x04\x1f\x38\x81\x47\xfb\x4c\xfd\xb4\x77"
> +	"\xa5\x24\x71\xf7\xa9\xa9\x69\x10\xb8\x55\x32\x2e\xdb\x63\x40\xd8"
> +	"\xa0\x0e\xf0\x92\x35\x05\x11\xe3\x0a\xbe\xc1\xff\xf9\xe3\xa2\x6e"
> +	"\x7f\xb2\x9f\x8c\x18\x30\x23\xc3\x58\x7e\x38\xda\x00\x77\xd9\xb4"
> +	"\x76\x3e\x4e\x4b\x94\xb2\xbb\xc1\x94\xc6\x65\x1e\x77\xca\xf9\x92"
> +	"\xee\xaa\xc0\x23\x2a\x28\x1b\xf6\xb3\xa7\x39\xc1\x22\x61\x16\x82"
> +	"\x0a\xe8\xdb\x58\x47\xa6\x7c\xbe\xf9\xc9\x09\x1b\x46\x2d\x53\x8c"
> +	"\xd7\x2b\x03\x74\x6a\xe7\x7f\x5e\x62\x29\x2c\x31\x15\x62\xa8\x46"
> +	"\x50\x5d\xc8\x2d\xb8\x54\x33\x8a\xe4\x9f\x52\x35\xc9\x5b\x91\x17"
> +	"\x8c\xcf\x2d\xd5\xca\xce\xf4\x03\xec\x9d\x18\x10\xc6\x27\x2b\x04"
> +	"\x5b\x3b\x71\xf9\xdc\x6b\x80\xd6\x3f\xdd\x4a\x8e\x9a\xdb\x1e\x69"
> +	"\x62\xa6\x95\x26\xd4\x31\x61\xc1\xa4\x1d\x57\x0d\x79\x38\xda\xd4"
> +	"\xa4\x0e\x32\x9c\xcf\xf4\x6a\xaa\x36\xad\x00\x4c\xf6\x00\xc8\x38"
> +	"\x1e\x42\x5a\x31\xd9\x51\xae\x64\xfd\xb2\x3f\xce\xc9\x50\x9d\x43"
> +	"\x68\x7f\xeb\x69\xed\xd1\xcc\x5e\x0b\x8c\xc3\xbd\xf6\x4b\x10\xef"
> +	"\x86\xb6\x31\x42\xa3\xab\x88\x29\x55\x5b\x2f\x74\x7c\x93\x26\x65"
> +	"\xcb\x2c\x0f\x1c\xc0\x1b\xd7\x02\x29\x38\x88\x39\xd2\xaf\x05\xe4"
> +	"\x54\x50\x4a\xc7\x8b\x75\x82\x82\x28\x46\xc0\xba\x35\xc3\x5f\x5c"
> +	"\x59\x16\x0c\xc0\x46\xfd\x82\x51\x54\x1f\xc6\x8c\x9c\x86\xb0\x22"
> +	"\xbb\x70\x99\x87\x6a\x46\x0e\x74\x51\xa8\xa9\x31\x09\x70\x3f\xee"
> +	"\x1c\x21\x7e\x6c\x38\x26\xe5\x2c\x51\xaa\x69\x1e\x0e\x42\x3c\xfc"
> +	"\x99\xe9\xe3\x16\x50\xc1\x21\x7b\x62\x48\x16\xcd\xad\x9a\x95\xf9"
> +	"\xd5\xb8\x01\x94\x88\xd9\xc0\xa0\xa1\xfe\x30\x75\xa5\x77\xe2\x31"
> +	"\x83\xf8\x1d\x4a\x3f\x2f\xa4\x57\x1e\xfc\x8c\xe0\xba\x8a\x4f\xe8"
> +	"\xb6\x85\x5d\xfe\x72\xb0\xa6\x6e\xde\xd2\xfb\xab\xfb\xe5\x8a\x30"
> +	"\xfa\xfa\xbe\x1c\x5d\x71\xa8\x7e\x2f\x74\x1e\xf8\xc1\xfe\x86\xfe"
> +	"\xa6\xbb\xfd\xe5\x30\x67\x7f\x0d\x97\xd1\x1d\x49\xf7\xa8\x44\x3d"
> +	"\x08\x22\xe5\x06\xa9\xf4\x61\x4e\x01\x1e\x2a\x94\x83\x8f\xf8\x8c"
> +	"\xd6\x8c\x8b\xb7\xc5\xc6\x42\x4c\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +#endif /* CONFIG_CRYPTO_DH_GROUPS_RFC7919 */
> +};
>   
>   /* 2 is used as a generator for all safe-prime groups. */
>   static const char safe_prime_group_g[]  = { 2 };
> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
> index 15d8b2dfe4a2..59be1fe3a978 100644
> --- a/include/crypto/dh.h
> +++ b/include/crypto/dh.h
> @@ -22,6 +22,13 @@
>   /** enum dh_group_id - identify well-known domain parameter sets */
>   enum dh_group_id {
>   	dh_group_id_unknown = 0,
> +#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC7919
> +	dh_group_id_rfc7919_ffdhe2048 = 1, /* Constant used by test vector. */
> +	dh_group_id_rfc7919_ffdhe3072,
> +	dh_group_id_rfc7919_ffdhe4096,
> +	dh_group_id_rfc7919_ffdhe6144,
> +	dh_group_id_rfc7919_ffdhe8192,
> +#endif
>   };
>   
>   /**
> 
Again, enums should be in upper case.
And I think the rfc7919 in dh_group_id_rfc7919_ffdheXXX is redundant; 
I'd rather leave it out and name is just dh_group_id_ffdheXXX.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 04/18] crypto: dh - introduce RFC 7919 safe-prime groups

[Nicolai Stange]

Hannes Reinecke <hare@suse.de> writes:

>> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
>> index 15d8b2dfe4a2..59be1fe3a978 100644
>> --- a/include/crypto/dh.h
>> +++ b/include/crypto/dh.h
>> @@ -22,6 +22,13 @@
>>   /** enum dh_group_id - identify well-known domain parameter sets */
>>   enum dh_group_id {
>>   	dh_group_id_unknown = 0,
>> +#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC7919
>> +	dh_group_id_rfc7919_ffdhe2048 = 1, /* Constant used by test vector. */
>> +	dh_group_id_rfc7919_ffdhe3072,
>> +	dh_group_id_rfc7919_ffdhe4096,
>> +	dh_group_id_rfc7919_ffdhe6144,
>> +	dh_group_id_rfc7919_ffdhe8192,
>> +#endif
>>   };
>>     /**
>>
> Again, enums should be in upper case.
> And I think the rfc7919 in dh_group_id_rfc7919_ffdheXXX is redundant;
> I'd rather leave it out and name is just dh_group_id_ffdheXXX.

All upper case now in v2 and those _RFCXYZ_ parts have also been
removed.

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

[PATCH 05/18] crypto: testmgr - add DH RFC 7919 ffdhe2048 test vector

[Nicolai Stange]

The previous patch introduced support for the safe-prime groups specified
by RFC 7919. In order to test this functionality, add a corresponding test
vector to testmgr. The test data has been generated with OpenSSL.

Note that this new entry provides test coverage for the recent change to
crypto_dh_encode_key(), which made it to skip the serialization of domain
parameters for known groups, i.e. those with
->group_id != dh_group_id_unknown.

Moreover, a future patch will make the DH implementation to reject domain
parameters not corresponding to some safe-prime group approved by
SP800-56Arev3 in FIPS mode and the existing DH test vectors don't qualify.
So this patch here will ensure that there's still some suitable test vector
available.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/testmgr.h | 94 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 93 insertions(+), 1 deletion(-)

diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index a8983c8626fa..ad1450c8e1e3 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1240,6 +1240,98 @@ static const struct akcipher_testvec pkcs1pad_rsa_tv_template[] = {
 };
 
 static const struct kpp_testvec dh_tv_template[] = {
+#if IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919)
+	{
+	.secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x01" /* len */
+	"\x01\x00\x00\x00" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x01\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x01\x14" /* len */
+	"\x00\x00\x00\x01" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x00\x01\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#endif
+	/* xa */
+	"\x23\x7d\xd0\x06\xfd\x7a\xe5\x7a\x08\xda\x98\x31\xc0\xb3\xd5\x85"
+	"\xe2\x0d\x2a\x91\x5f\x78\x4b\xa6\x62\xd0\xa6\x35\xd4\xef\x86\x39"
+	"\xf1\xdb\x71\x5e\xb0\x11\x2e\xee\x91\x3a\xaa\xf9\xe3\xdf\x8d\x8b"
+	"\x48\x41\xde\xe8\x78\x53\xc5\x5f\x93\xd2\x79\x0d\xbe\x8d\x83\xe8"
+	"\x8f\x00\xd2\xde\x13\x18\x04\x05\x20\x6d\xda\xfa\x1d\x0b\x24\x52"
+	"\x3a\x18\x2b\xe1\x1e\xae\x15\x3b\x0f\xaa\x09\x09\xf6\x01\x98\xe9"
+	"\x81\x5d\x6b\x83\x6e\x55\xf1\x5d\x6f\x6f\x0d\x9d\xa8\x72\x32\x63"
+	"\x60\xe6\x0b\xc5\x22\xe2\xf9\x46\x58\xa2\x1c\x2a\xb0\xd5\xaf\xe3"
+	"\x5b\x03\xb7\x36\xb7\xba\x55\x20\x08\x7c\x51\xd4\x89\x42\x9c\x14"
+	"\x23\xe2\x71\x3e\x15\x2a\x0d\x34\x8a\xde\xad\x84\x11\x15\x72\x18"
+	"\x42\x43\x0a\xe2\x58\x29\xb3\x90\x0f\x56\xd8\x8a\x0f\x0e\xbc\x0e"
+	"\x9c\xe7\xd5\xe6\x5b\xbf\x06\x64\x38\x12\xa5\x8d\x5b\x68\x34\xdd"
+	"\x75\x48\xc9\xa7\xa3\x58\x5a\x1c\xe1\xb2\xc5\xe3\x39\x03\xcf\xab"
+	"\xc2\x14\x07\xaf\x55\x80\xc7\x63\xe4\x03\xeb\xe9\x0a\x25\x61\x85"
+	"\x1d\x0e\x81\x52\x7b\xbc\x4a\x0c\xc8\x59\x6a\xac\x18\xfb\x8c\x0c"
+	"\xb4\x79\xbd\xa1\x4c\xbb\x02\xc9\xd5\x13\x88\x3d\x25\xaa\x77\x49",
+	.b_public =
+	"\x5c\x00\x6f\xda\xfe\x4c\x0c\xc2\x18\xff\xa9\xec\x7a\xbe\x8a\x51"
+	"\x64\x6b\x57\xf8\xed\xe2\x36\x77\xc1\x23\xbf\x56\xa6\x48\x76\x34"
+	"\x0e\xf3\x68\x05\x45\x6a\x98\x5b\x9e\x8b\xc0\x11\x29\xcb\x5b\x66"
+	"\x2d\xc2\xeb\x4c\xf1\x7d\x85\x30\xaa\xd5\xf5\xb8\xd3\x62\x1e\x97"
+	"\x1e\x34\x18\xf8\x76\x8c\x10\xca\x1f\xe4\x5d\x62\xe1\xbe\x61\xef"
+	"\xaf\x2c\x8d\x97\x15\xa5\x86\xd5\xd3\x12\x6f\xec\xe2\xa4\xb2\x5a"
+	"\x35\x1d\xd4\x91\xa6\xef\x13\x09\x65\x9c\x45\xc0\x12\xad\x7f\xee"
+	"\x93\x5d\xfa\x89\x26\x7d\xae\xee\xea\x8c\xa3\xcf\x04\x2d\xa0\xc7"
+	"\xd9\x14\x62\xaf\xdf\xa0\x33\xd7\x5e\x83\xa2\xe6\x0e\x0e\x5d\x77"
+	"\xce\xe6\x72\xe4\xec\x9d\xff\x72\x9f\x38\x95\x19\x96\xba\x4c\xe3"
+	"\x5f\xb8\x46\x4a\x1d\xe9\x62\x7b\xa8\xdc\xe7\x61\x90\x6b\xb9\xd4"
+	"\xad\x0b\xa3\x06\xb3\x70\xfa\xea\x2b\xc4\x2c\xde\x43\x37\xf6\x8d"
+	"\x72\xf0\x86\x9a\xbb\x3b\x8e\x7a\x71\x03\x30\x30\x2a\x5d\xcd\x1e"
+	"\xe4\xd3\x08\x07\x75\x17\x17\x72\x1e\x77\x6c\x98\x0d\x29\x7f\xac"
+	"\xe7\xb2\xee\xa9\x1c\x33\x9d\x08\x39\xe1\xd8\x5b\xe5\xbc\x48\xb2"
+	"\xb6\xdf\xcd\xa0\x42\x06\xcc\xfb\xed\x60\x6f\xbc\x57\xac\x09\x45",
+	.expected_a_public =
+	"\x8b\xdb\xc1\xf7\xc6\xba\xa1\x38\x95\x6a\xa1\xb6\x04\x5e\xae\x52"
+	"\x72\xfc\xef\x2d\x9d\x71\x05\x9c\xd3\x02\xa9\xfb\x55\x0f\xfa\xc9"
+	"\xb4\x34\x51\xa3\x28\x89\x8d\x93\x92\xcb\xd9\xb5\xb9\x66\xfc\x67"
+	"\x15\x92\x6f\x73\x85\x15\xe2\xfc\x11\x6b\x97\x8c\x4b\x0f\x12\xfa"
+	"\x8d\x72\x76\x9b\x8f\x3b\xfe\x31\xbe\x42\x88\x4c\xd2\xb2\x70\xa6"
+	"\xa5\xe3\x7e\x73\x07\x12\x36\xaa\xc9\x5c\x83\xe1\xf1\x46\x41\x4f"
+	"\x7c\x52\xaf\xdc\xa4\xe6\x82\xa3\x86\x83\x47\x5a\x12\x3a\x0c\xe3"
+	"\xdd\xdb\x94\x03\x2a\x59\x91\xa0\x19\xe5\xf8\x07\xdd\x54\x6a\x22"
+	"\x43\xb7\xf3\x74\xd7\xb9\x30\xfe\x9c\xe8\xd1\xcf\x06\x43\x68\xb9"
+	"\x54\x8f\x54\xa2\xe5\x3c\xf2\xc3\x4c\xee\xd4\x7c\x5d\x0e\xb1\x7b"
+	"\x16\x68\xb5\xb3\x7d\xd4\x11\x83\x5c\x77\x17\xc4\xf0\x59\x76\x7a"
+	"\x83\x40\xe5\xd9\x4c\x76\x23\x5b\x17\x6d\xee\x4a\x92\x68\x4b\x89"
+	"\xa0\x6d\x23\x8c\x80\x31\x33\x3a\x12\xf4\x50\xa6\xcb\x13\x97\x01"
+	"\xb8\x2c\xe6\xd2\x38\xdf\xd0\x7f\xc6\x27\x19\x0e\xb2\x07\xfd\x1f"
+	"\x1b\x9c\x1b\x87\xf9\x73\x6a\x3f\x7f\xb0\xf9\x2f\x3c\x19\x9f\xc9"
+	"\x8f\x97\x21\x0e\x8e\xbb\x1a\x17\x20\x15\xdd\xc6\x42\x60\xae\x4d",
+	.expected_ss =
+	"\xf3\x0e\x64\x7b\x66\xd7\x82\x7e\xab\x7e\x4a\xbe\x13\x6f\x43\x3d"
+	"\xea\x4f\x1f\x8b\x9d\x41\x56\x71\xe1\x06\x96\x02\x68\xfa\x44\x6e"
+	"\xe7\xf2\x26\xd4\x01\x4a\xf0\x28\x25\x76\xad\xd7\xe0\x17\x74\xfe"
+	"\xf9\xe1\x6d\xd3\xf7\xc7\xdf\xc0\x62\xa5\xf3\x4e\x1b\x5c\x77\x2a"
+	"\xfb\x0b\x87\xc3\xde\x1e\xc1\xe0\xd3\x7a\xb8\x02\x02\xec\x9c\x97"
+	"\xfb\x34\xa0\x20\x10\x23\x87\xb2\x9a\x72\xe3\x3d\xb2\x18\x50\xf3"
+	"\x6a\xd3\xd3\x19\xc4\x36\xd5\x59\xd6\xd6\xa7\x5c\xc3\xf9\x09\x33"
+	"\xa1\xf5\xb9\x4b\xf3\x0b\xe1\x4f\x79\x6b\x45\xf2\xec\x8b\xe5\x69"
+	"\x9f\xc6\x05\x01\xfe\x3a\x13\xfd\x6d\xea\x03\x83\x29\x7c\x7f\xf5"
+	"\x41\x55\x95\xde\x7e\x62\xae\xaf\x28\xdb\x7c\xa9\x90\x1e\xb2\xb1"
+	"\x1b\xef\xf1\x2e\xde\x47\xaa\xa8\x92\x9a\x49\x3d\xc0\xe0\x8d\xbb"
+	"\x0c\x42\x86\xaf\x00\xce\xb0\xab\x22\x7c\xe9\xbe\xb9\x72\x2f\xcf"
+	"\x5e\x5d\x62\x52\x2a\xd1\xfe\xcc\xa2\xf3\x40\xfd\x01\xa7\x54\x0a"
+	"\xa1\xfb\x1c\xf2\x44\xa6\x47\x30\x5a\xba\x2a\x05\xff\xd0\x6c\xab"
+	"\xeb\xe6\x8f\xf6\xd7\x73\xa3\x0e\x6c\x0e\xcf\xfd\x8e\x16\x5d\xe0"
+	"\x2c\x11\x05\x82\x3c\x22\x16\x6c\x52\x61\xcf\xbb\xff\xf8\x06\xd0",
+	.secret_size = 276,
+	.b_public_size = 256,
+	.expected_a_public_size = 256,
+	.expected_ss_size = 256,
+	},
+#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919) */
 	{
 	.secret =
 #ifdef __LITTLE_ENDIAN
@@ -1457,7 +1549,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.b_public_size = 256,
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
-	}
+	},
 };
 
 static const struct kpp_testvec curve25519_tv_template[] = {
-- 
2.26.2

Re: [PATCH 05/18] crypto: testmgr - add DH RFC 7919 ffdhe2048 test vector

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> The previous patch introduced support for the safe-prime groups specified
> by RFC 7919. In order to test this functionality, add a corresponding test
> vector to testmgr. The test data has been generated with OpenSSL.
> 
> Note that this new entry provides test coverage for the recent change to
> crypto_dh_encode_key(), which made it to skip the serialization of domain
> parameters for known groups, i.e. those with
> ->group_id != dh_group_id_unknown.
> 
> Moreover, a future patch will make the DH implementation to reject domain
> parameters not corresponding to some safe-prime group approved by
> SP800-56Arev3 in FIPS mode and the existing DH test vectors don't qualify.
> So this patch here will ensure that there's still some suitable test vector
> available.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/testmgr.h | 94 +++++++++++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 93 insertions(+), 1 deletion(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 06/18] crypto: dh - introduce RFC 3526 safe-prime groups

[Nicolai Stange]

A future patch will make the DH implementation to reject domain parameters
not corresponding to any of the safe-prime groups approved by SP800-56Arev3
in FIPS mode.

The MODP groups specified by RFC 3526 are among those approved safe-prime
groups. Make them known to the kernel in order to enable the DH
implementation to recognize those when passed in from e.g. the
keyctl(KEYCTL_DH_COMPUTE) syscall.

More specifically, introduce corresponding members to enum dh_group_id
as well as entries with the resp. domain parameters to the
safe_prime_groups[] array queried by crypto_dh_decode_key(). The resp.
->max_strength value is set to the maximum supported security strength as
specified in SP800-56Arev3.

As the domain parameters consume an substantial amount of space, make
RFC 3526 safe-prime group support selectable by means of the new
CRYPTO_DH_GROUPS_RFC3526 Kconfig option.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/Kconfig      |   6 ++
 crypto/dh_helper.c  | 216 ++++++++++++++++++++++++++++++++++++++++++++
 include/crypto/dh.h |   7 ++
 3 files changed, 229 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 0f039bbf36e2..fcb044bdc90a 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -238,6 +238,12 @@ config CRYPTO_DH_GROUPS_RFC7919
 	  Enable to allow for the use of RFC 7919 DH parameters in FIPS mode,
 	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
 
+config CRYPTO_DH_GROUPS_RFC3526
+	bool "Support for RFC 3526 MODP group parameters"
+	help
+	  Enable to allow for the use of RFC 3526 DH parameters in FIPS mode,
+	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
+
 endif
 
 config CRYPTO_ECC
diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index 83744c3bfc17..fb8df4734dc1 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -236,6 +236,222 @@ static const struct safe_prime_group
 	"\xd6\x8c\x8b\xb7\xc5\xc6\x42\x4c\xff\xff\xff\xff\xff\xff\xff\xff",
 	},
 #endif /* CONFIG_CRYPTO_DH_GROUPS_RFC7919 */
+#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC3526
+	{
+	.group_id = dh_group_id_rfc3526_modp2048,
+	.max_strength = 112,
+	.p_size = 256,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
+	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
+	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
+	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
+	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
+	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
+	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
+	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
+	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
+	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
+	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
+	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
+	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
+	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
+	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
+	"\x15\x72\x8e\x5a\x8a\xac\xaa\x68\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc3526_modp3072,
+	.max_strength = 128,
+	.p_size = 384,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
+	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
+	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
+	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
+	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
+	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
+	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
+	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
+	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
+	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
+	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
+	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
+	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
+	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
+	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
+	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
+	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
+	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
+	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
+	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
+	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
+	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
+	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
+	"\x4b\x82\xd1\x20\xa9\x3a\xd2\xca\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc3526_modp4096,
+	.max_strength = 152,
+	.p_size = 512,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
+	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
+	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
+	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
+	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
+	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
+	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
+	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
+	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
+	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
+	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
+	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
+	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
+	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
+	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
+	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
+	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
+	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
+	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
+	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
+	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
+	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
+	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
+	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
+	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
+	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
+	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
+	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
+	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
+	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
+	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
+	"\x4d\xf4\x35\xc9\x34\x06\x31\x99\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc3526_modp6144,
+	.max_strength = 176,
+	.p_size = 768,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
+	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
+	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
+	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
+	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
+	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
+	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
+	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
+	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
+	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
+	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
+	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
+	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
+	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
+	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
+	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
+	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
+	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
+	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
+	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
+	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
+	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
+	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
+	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
+	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
+	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
+	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
+	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
+	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
+	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
+	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
+	"\x4d\xf4\x35\xc9\x34\x02\x84\x92\x36\xc3\xfa\xb4\xd2\x7c\x70\x26"
+	"\xc1\xd4\xdc\xb2\x60\x26\x46\xde\xc9\x75\x1e\x76\x3d\xba\x37\xbd"
+	"\xf8\xff\x94\x06\xad\x9e\x53\x0e\xe5\xdb\x38\x2f\x41\x30\x01\xae"
+	"\xb0\x6a\x53\xed\x90\x27\xd8\x31\x17\x97\x27\xb0\x86\x5a\x89\x18"
+	"\xda\x3e\xdb\xeb\xcf\x9b\x14\xed\x44\xce\x6c\xba\xce\xd4\xbb\x1b"
+	"\xdb\x7f\x14\x47\xe6\xcc\x25\x4b\x33\x20\x51\x51\x2b\xd7\xaf\x42"
+	"\x6f\xb8\xf4\x01\x37\x8c\xd2\xbf\x59\x83\xca\x01\xc6\x4b\x92\xec"
+	"\xf0\x32\xea\x15\xd1\x72\x1d\x03\xf4\x82\xd7\xce\x6e\x74\xfe\xf6"
+	"\xd5\x5e\x70\x2f\x46\x98\x0c\x82\xb5\xa8\x40\x31\x90\x0b\x1c\x9e"
+	"\x59\xe7\xc9\x7f\xbe\xc7\xe8\xf3\x23\xa9\x7a\x7e\x36\xcc\x88\xbe"
+	"\x0f\x1d\x45\xb7\xff\x58\x5a\xc5\x4b\xd4\x07\xb2\x2b\x41\x54\xaa"
+	"\xcc\x8f\x6d\x7e\xbf\x48\xe1\xd8\x14\xcc\x5e\xd2\x0f\x80\x37\xe0"
+	"\xa7\x97\x15\xee\xf2\x9b\xe3\x28\x06\xa1\xd5\x8b\xb7\xc5\xda\x76"
+	"\xf5\x50\xaa\x3d\x8a\x1f\xbf\xf0\xeb\x19\xcc\xb1\xa3\x13\xd5\x5c"
+	"\xda\x56\xc9\xec\x2e\xf2\x96\x32\x38\x7f\xe8\xd7\x6e\x3c\x04\x68"
+	"\x04\x3e\x8f\x66\x3f\x48\x60\xee\x12\xbf\x2d\x5b\x0b\x74\x74\xd6"
+	"\xe6\x94\xf9\x1e\x6d\xcc\x40\x24\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+	{
+	.group_id = dh_group_id_rfc3526_modp8192,
+	.max_strength = 200,
+	.p_size = 1024,
+	.p =
+	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
+	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
+	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
+	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
+	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
+	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
+	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
+	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
+	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
+	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
+	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
+	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
+	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
+	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
+	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
+	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
+	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
+	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
+	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
+	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
+	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
+	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
+	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
+	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
+	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
+	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
+	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
+	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
+	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
+	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
+	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
+	"\x4d\xf4\x35\xc9\x34\x02\x84\x92\x36\xc3\xfa\xb4\xd2\x7c\x70\x26"
+	"\xc1\xd4\xdc\xb2\x60\x26\x46\xde\xc9\x75\x1e\x76\x3d\xba\x37\xbd"
+	"\xf8\xff\x94\x06\xad\x9e\x53\x0e\xe5\xdb\x38\x2f\x41\x30\x01\xae"
+	"\xb0\x6a\x53\xed\x90\x27\xd8\x31\x17\x97\x27\xb0\x86\x5a\x89\x18"
+	"\xda\x3e\xdb\xeb\xcf\x9b\x14\xed\x44\xce\x6c\xba\xce\xd4\xbb\x1b"
+	"\xdb\x7f\x14\x47\xe6\xcc\x25\x4b\x33\x20\x51\x51\x2b\xd7\xaf\x42"
+	"\x6f\xb8\xf4\x01\x37\x8c\xd2\xbf\x59\x83\xca\x01\xc6\x4b\x92\xec"
+	"\xf0\x32\xea\x15\xd1\x72\x1d\x03\xf4\x82\xd7\xce\x6e\x74\xfe\xf6"
+	"\xd5\x5e\x70\x2f\x46\x98\x0c\x82\xb5\xa8\x40\x31\x90\x0b\x1c\x9e"
+	"\x59\xe7\xc9\x7f\xbe\xc7\xe8\xf3\x23\xa9\x7a\x7e\x36\xcc\x88\xbe"
+	"\x0f\x1d\x45\xb7\xff\x58\x5a\xc5\x4b\xd4\x07\xb2\x2b\x41\x54\xaa"
+	"\xcc\x8f\x6d\x7e\xbf\x48\xe1\xd8\x14\xcc\x5e\xd2\x0f\x80\x37\xe0"
+	"\xa7\x97\x15\xee\xf2\x9b\xe3\x28\x06\xa1\xd5\x8b\xb7\xc5\xda\x76"
+	"\xf5\x50\xaa\x3d\x8a\x1f\xbf\xf0\xeb\x19\xcc\xb1\xa3\x13\xd5\x5c"
+	"\xda\x56\xc9\xec\x2e\xf2\x96\x32\x38\x7f\xe8\xd7\x6e\x3c\x04\x68"
+	"\x04\x3e\x8f\x66\x3f\x48\x60\xee\x12\xbf\x2d\x5b\x0b\x74\x74\xd6"
+	"\xe6\x94\xf9\x1e\x6d\xbe\x11\x59\x74\xa3\x92\x6f\x12\xfe\xe5\xe4"
+	"\x38\x77\x7c\xb6\xa9\x32\xdf\x8c\xd8\xbe\xc4\xd0\x73\xb9\x31\xba"
+	"\x3b\xc8\x32\xb6\x8d\x9d\xd3\x00\x74\x1f\xa7\xbf\x8a\xfc\x47\xed"
+	"\x25\x76\xf6\x93\x6b\xa4\x24\x66\x3a\xab\x63\x9c\x5a\xe4\xf5\x68"
+	"\x34\x23\xb4\x74\x2b\xf1\xc9\x78\x23\x8f\x16\xcb\xe3\x9d\x65\x2d"
+	"\xe3\xfd\xb8\xbe\xfc\x84\x8a\xd9\x22\x22\x2e\x04\xa4\x03\x7c\x07"
+	"\x13\xeb\x57\xa8\x1a\x23\xf0\xc7\x34\x73\xfc\x64\x6c\xea\x30\x6b"
+	"\x4b\xcb\xc8\x86\x2f\x83\x85\xdd\xfa\x9d\x4b\x7f\xa2\xc0\x87\xe8"
+	"\x79\x68\x33\x03\xed\x5b\xdd\x3a\x06\x2b\x3c\xf5\xb3\xa2\x78\xa6"
+	"\x6d\x2a\x13\xf8\x3f\x44\xf8\x2d\xdf\x31\x0e\xe0\x74\xab\x6a\x36"
+	"\x45\x97\xe8\x99\xa0\x25\x5d\xc1\x64\xf3\x1c\xc5\x08\x46\x85\x1d"
+	"\xf9\xab\x48\x19\x5d\xed\x7e\xa1\xb1\xd5\x10\xbd\x7e\xe7\x4d\x73"
+	"\xfa\xf3\x6b\xc3\x1e\xcf\xa2\x68\x35\x90\x46\xf4\xeb\x87\x9f\x92"
+	"\x40\x09\x43\x8b\x48\x1c\x6c\xd7\x88\x9a\x00\x2e\xd5\xee\x38\x2b"
+	"\xc9\x19\x0d\xa6\xfc\x02\x6e\x47\x95\x58\xe4\x47\x56\x77\xe9\xaa"
+	"\x9e\x30\x50\xe2\x76\x56\x94\xdf\xc8\x1f\x56\xe8\x80\xb9\x6e\x71"
+	"\x60\xc9\x80\xdd\x98\xed\xd3\xdf\xff\xff\xff\xff\xff\xff\xff\xff",
+	},
+#endif /* CONFIG_CRYPTO_DH_GROUPS_RFC3526 */
 };
 
 /* 2 is used as a generator for all safe-prime groups. */
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 59be1fe3a978..7eb1fad93d02 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -29,6 +29,13 @@ enum dh_group_id {
 	dh_group_id_rfc7919_ffdhe6144,
 	dh_group_id_rfc7919_ffdhe8192,
 #endif
+#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC3526
+	dh_group_id_rfc3526_modp2048 = 6, /* Constant used by test vector. */
+	dh_group_id_rfc3526_modp3072,
+	dh_group_id_rfc3526_modp4096,
+	dh_group_id_rfc3526_modp6144,
+	dh_group_id_rfc3526_modp8192,
+#endif
 };
 
 /**
-- 
2.26.2

Re: [PATCH 06/18] crypto: dh - introduce RFC 3526 safe-prime groups

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A future patch will make the DH implementation to reject domain parameters
> not corresponding to any of the safe-prime groups approved by SP800-56Arev3
> in FIPS mode.
> 
> The MODP groups specified by RFC 3526 are among those approved safe-prime
> groups. Make them known to the kernel in order to enable the DH
> implementation to recognize those when passed in from e.g. the
> keyctl(KEYCTL_DH_COMPUTE) syscall.
> 
> More specifically, introduce corresponding members to enum dh_group_id
> as well as entries with the resp. domain parameters to the
> safe_prime_groups[] array queried by crypto_dh_decode_key(). The resp.
> ->max_strength value is set to the maximum supported security strength as
> specified in SP800-56Arev3.
> 
> As the domain parameters consume an substantial amount of space, make
> RFC 3526 safe-prime group support selectable by means of the new
> CRYPTO_DH_GROUPS_RFC3526 Kconfig option.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/Kconfig      |   6 ++
>   crypto/dh_helper.c  | 216 ++++++++++++++++++++++++++++++++++++++++++++
>   include/crypto/dh.h |   7 ++
>   3 files changed, 229 insertions(+)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 0f039bbf36e2..fcb044bdc90a 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -238,6 +238,12 @@ config CRYPTO_DH_GROUPS_RFC7919
>   	  Enable to allow for the use of RFC 7919 DH parameters in FIPS mode,
>   	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
>   
> +config CRYPTO_DH_GROUPS_RFC3526
> +	bool "Support for RFC 3526 MODP group parameters"
> +	help
> +	  Enable to allow for the use of RFC 3526 DH parameters in FIPS mode,
> +	  e.g. via keyctl(KEYCTL_DH_COMPUTE). Otherwise it's safe to say N.
> +
>   endif
>   
>   config CRYPTO_ECC
> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
> index 83744c3bfc17..fb8df4734dc1 100644
> --- a/crypto/dh_helper.c
> +++ b/crypto/dh_helper.c
> @@ -236,6 +236,222 @@ static const struct safe_prime_group
>   	"\xd6\x8c\x8b\xb7\xc5\xc6\x42\x4c\xff\xff\xff\xff\xff\xff\xff\xff",
>   	},
>   #endif /* CONFIG_CRYPTO_DH_GROUPS_RFC7919 */
> +#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC3526
> +	{
> +	.group_id = dh_group_id_rfc3526_modp2048,
> +	.max_strength = 112,
> +	.p_size = 256,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
> +	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
> +	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
> +	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
> +	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
> +	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
> +	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
> +	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
> +	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
> +	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
> +	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
> +	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
> +	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
> +	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
> +	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
> +	"\x15\x72\x8e\x5a\x8a\xac\xaa\x68\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc3526_modp3072,
> +	.max_strength = 128,
> +	.p_size = 384,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
> +	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
> +	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
> +	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
> +	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
> +	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
> +	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
> +	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
> +	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
> +	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
> +	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
> +	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
> +	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
> +	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
> +	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
> +	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
> +	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
> +	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
> +	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
> +	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
> +	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
> +	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
> +	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
> +	"\x4b\x82\xd1\x20\xa9\x3a\xd2\xca\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc3526_modp4096,
> +	.max_strength = 152,
> +	.p_size = 512,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
> +	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
> +	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
> +	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
> +	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
> +	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
> +	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
> +	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
> +	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
> +	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
> +	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
> +	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
> +	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
> +	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
> +	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
> +	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
> +	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
> +	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
> +	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
> +	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
> +	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
> +	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
> +	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
> +	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
> +	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
> +	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
> +	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
> +	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
> +	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
> +	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
> +	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
> +	"\x4d\xf4\x35\xc9\x34\x06\x31\x99\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc3526_modp6144,
> +	.max_strength = 176,
> +	.p_size = 768,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
> +	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
> +	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
> +	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
> +	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
> +	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
> +	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
> +	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
> +	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
> +	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
> +	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
> +	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
> +	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
> +	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
> +	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
> +	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
> +	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
> +	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
> +	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
> +	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
> +	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
> +	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
> +	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
> +	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
> +	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
> +	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
> +	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
> +	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
> +	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
> +	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
> +	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
> +	"\x4d\xf4\x35\xc9\x34\x02\x84\x92\x36\xc3\xfa\xb4\xd2\x7c\x70\x26"
> +	"\xc1\xd4\xdc\xb2\x60\x26\x46\xde\xc9\x75\x1e\x76\x3d\xba\x37\xbd"
> +	"\xf8\xff\x94\x06\xad\x9e\x53\x0e\xe5\xdb\x38\x2f\x41\x30\x01\xae"
> +	"\xb0\x6a\x53\xed\x90\x27\xd8\x31\x17\x97\x27\xb0\x86\x5a\x89\x18"
> +	"\xda\x3e\xdb\xeb\xcf\x9b\x14\xed\x44\xce\x6c\xba\xce\xd4\xbb\x1b"
> +	"\xdb\x7f\x14\x47\xe6\xcc\x25\x4b\x33\x20\x51\x51\x2b\xd7\xaf\x42"
> +	"\x6f\xb8\xf4\x01\x37\x8c\xd2\xbf\x59\x83\xca\x01\xc6\x4b\x92\xec"
> +	"\xf0\x32\xea\x15\xd1\x72\x1d\x03\xf4\x82\xd7\xce\x6e\x74\xfe\xf6"
> +	"\xd5\x5e\x70\x2f\x46\x98\x0c\x82\xb5\xa8\x40\x31\x90\x0b\x1c\x9e"
> +	"\x59\xe7\xc9\x7f\xbe\xc7\xe8\xf3\x23\xa9\x7a\x7e\x36\xcc\x88\xbe"
> +	"\x0f\x1d\x45\xb7\xff\x58\x5a\xc5\x4b\xd4\x07\xb2\x2b\x41\x54\xaa"
> +	"\xcc\x8f\x6d\x7e\xbf\x48\xe1\xd8\x14\xcc\x5e\xd2\x0f\x80\x37\xe0"
> +	"\xa7\x97\x15\xee\xf2\x9b\xe3\x28\x06\xa1\xd5\x8b\xb7\xc5\xda\x76"
> +	"\xf5\x50\xaa\x3d\x8a\x1f\xbf\xf0\xeb\x19\xcc\xb1\xa3\x13\xd5\x5c"
> +	"\xda\x56\xc9\xec\x2e\xf2\x96\x32\x38\x7f\xe8\xd7\x6e\x3c\x04\x68"
> +	"\x04\x3e\x8f\x66\x3f\x48\x60\xee\x12\xbf\x2d\x5b\x0b\x74\x74\xd6"
> +	"\xe6\x94\xf9\x1e\x6d\xcc\x40\x24\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +	{
> +	.group_id = dh_group_id_rfc3526_modp8192,
> +	.max_strength = 200,
> +	.p_size = 1024,
> +	.p =
> +	"\xff\xff\xff\xff\xff\xff\xff\xff\xc9\x0f\xda\xa2\x21\x68\xc2\x34"
> +	"\xc4\xc6\x62\x8b\x80\xdc\x1c\xd1\x29\x02\x4e\x08\x8a\x67\xcc\x74"
> +	"\x02\x0b\xbe\xa6\x3b\x13\x9b\x22\x51\x4a\x08\x79\x8e\x34\x04\xdd"
> +	"\xef\x95\x19\xb3\xcd\x3a\x43\x1b\x30\x2b\x0a\x6d\xf2\x5f\x14\x37"
> +	"\x4f\xe1\x35\x6d\x6d\x51\xc2\x45\xe4\x85\xb5\x76\x62\x5e\x7e\xc6"
> +	"\xf4\x4c\x42\xe9\xa6\x37\xed\x6b\x0b\xff\x5c\xb6\xf4\x06\xb7\xed"
> +	"\xee\x38\x6b\xfb\x5a\x89\x9f\xa5\xae\x9f\x24\x11\x7c\x4b\x1f\xe6"
> +	"\x49\x28\x66\x51\xec\xe4\x5b\x3d\xc2\x00\x7c\xb8\xa1\x63\xbf\x05"
> +	"\x98\xda\x48\x36\x1c\x55\xd3\x9a\x69\x16\x3f\xa8\xfd\x24\xcf\x5f"
> +	"\x83\x65\x5d\x23\xdc\xa3\xad\x96\x1c\x62\xf3\x56\x20\x85\x52\xbb"
> +	"\x9e\xd5\x29\x07\x70\x96\x96\x6d\x67\x0c\x35\x4e\x4a\xbc\x98\x04"
> +	"\xf1\x74\x6c\x08\xca\x18\x21\x7c\x32\x90\x5e\x46\x2e\x36\xce\x3b"
> +	"\xe3\x9e\x77\x2c\x18\x0e\x86\x03\x9b\x27\x83\xa2\xec\x07\xa2\x8f"
> +	"\xb5\xc5\x5d\xf0\x6f\x4c\x52\xc9\xde\x2b\xcb\xf6\x95\x58\x17\x18"
> +	"\x39\x95\x49\x7c\xea\x95\x6a\xe5\x15\xd2\x26\x18\x98\xfa\x05\x10"
> +	"\x15\x72\x8e\x5a\x8a\xaa\xc4\x2d\xad\x33\x17\x0d\x04\x50\x7a\x33"
> +	"\xa8\x55\x21\xab\xdf\x1c\xba\x64\xec\xfb\x85\x04\x58\xdb\xef\x0a"
> +	"\x8a\xea\x71\x57\x5d\x06\x0c\x7d\xb3\x97\x0f\x85\xa6\xe1\xe4\xc7"
> +	"\xab\xf5\xae\x8c\xdb\x09\x33\xd7\x1e\x8c\x94\xe0\x4a\x25\x61\x9d"
> +	"\xce\xe3\xd2\x26\x1a\xd2\xee\x6b\xf1\x2f\xfa\x06\xd9\x8a\x08\x64"
> +	"\xd8\x76\x02\x73\x3e\xc8\x6a\x64\x52\x1f\x2b\x18\x17\x7b\x20\x0c"
> +	"\xbb\xe1\x17\x57\x7a\x61\x5d\x6c\x77\x09\x88\xc0\xba\xd9\x46\xe2"
> +	"\x08\xe2\x4f\xa0\x74\xe5\xab\x31\x43\xdb\x5b\xfc\xe0\xfd\x10\x8e"
> +	"\x4b\x82\xd1\x20\xa9\x21\x08\x01\x1a\x72\x3c\x12\xa7\x87\xe6\xd7"
> +	"\x88\x71\x9a\x10\xbd\xba\x5b\x26\x99\xc3\x27\x18\x6a\xf4\xe2\x3c"
> +	"\x1a\x94\x68\x34\xb6\x15\x0b\xda\x25\x83\xe9\xca\x2a\xd4\x4c\xe8"
> +	"\xdb\xbb\xc2\xdb\x04\xde\x8e\xf9\x2e\x8e\xfc\x14\x1f\xbe\xca\xa6"
> +	"\x28\x7c\x59\x47\x4e\x6b\xc0\x5d\x99\xb2\x96\x4f\xa0\x90\xc3\xa2"
> +	"\x23\x3b\xa1\x86\x51\x5b\xe7\xed\x1f\x61\x29\x70\xce\xe2\xd7\xaf"
> +	"\xb8\x1b\xdd\x76\x21\x70\x48\x1c\xd0\x06\x91\x27\xd5\xb0\x5a\xa9"
> +	"\x93\xb4\xea\x98\x8d\x8f\xdd\xc1\x86\xff\xb7\xdc\x90\xa6\xc0\x8f"
> +	"\x4d\xf4\x35\xc9\x34\x02\x84\x92\x36\xc3\xfa\xb4\xd2\x7c\x70\x26"
> +	"\xc1\xd4\xdc\xb2\x60\x26\x46\xde\xc9\x75\x1e\x76\x3d\xba\x37\xbd"
> +	"\xf8\xff\x94\x06\xad\x9e\x53\x0e\xe5\xdb\x38\x2f\x41\x30\x01\xae"
> +	"\xb0\x6a\x53\xed\x90\x27\xd8\x31\x17\x97\x27\xb0\x86\x5a\x89\x18"
> +	"\xda\x3e\xdb\xeb\xcf\x9b\x14\xed\x44\xce\x6c\xba\xce\xd4\xbb\x1b"
> +	"\xdb\x7f\x14\x47\xe6\xcc\x25\x4b\x33\x20\x51\x51\x2b\xd7\xaf\x42"
> +	"\x6f\xb8\xf4\x01\x37\x8c\xd2\xbf\x59\x83\xca\x01\xc6\x4b\x92\xec"
> +	"\xf0\x32\xea\x15\xd1\x72\x1d\x03\xf4\x82\xd7\xce\x6e\x74\xfe\xf6"
> +	"\xd5\x5e\x70\x2f\x46\x98\x0c\x82\xb5\xa8\x40\x31\x90\x0b\x1c\x9e"
> +	"\x59\xe7\xc9\x7f\xbe\xc7\xe8\xf3\x23\xa9\x7a\x7e\x36\xcc\x88\xbe"
> +	"\x0f\x1d\x45\xb7\xff\x58\x5a\xc5\x4b\xd4\x07\xb2\x2b\x41\x54\xaa"
> +	"\xcc\x8f\x6d\x7e\xbf\x48\xe1\xd8\x14\xcc\x5e\xd2\x0f\x80\x37\xe0"
> +	"\xa7\x97\x15\xee\xf2\x9b\xe3\x28\x06\xa1\xd5\x8b\xb7\xc5\xda\x76"
> +	"\xf5\x50\xaa\x3d\x8a\x1f\xbf\xf0\xeb\x19\xcc\xb1\xa3\x13\xd5\x5c"
> +	"\xda\x56\xc9\xec\x2e\xf2\x96\x32\x38\x7f\xe8\xd7\x6e\x3c\x04\x68"
> +	"\x04\x3e\x8f\x66\x3f\x48\x60\xee\x12\xbf\x2d\x5b\x0b\x74\x74\xd6"
> +	"\xe6\x94\xf9\x1e\x6d\xbe\x11\x59\x74\xa3\x92\x6f\x12\xfe\xe5\xe4"
> +	"\x38\x77\x7c\xb6\xa9\x32\xdf\x8c\xd8\xbe\xc4\xd0\x73\xb9\x31\xba"
> +	"\x3b\xc8\x32\xb6\x8d\x9d\xd3\x00\x74\x1f\xa7\xbf\x8a\xfc\x47\xed"
> +	"\x25\x76\xf6\x93\x6b\xa4\x24\x66\x3a\xab\x63\x9c\x5a\xe4\xf5\x68"
> +	"\x34\x23\xb4\x74\x2b\xf1\xc9\x78\x23\x8f\x16\xcb\xe3\x9d\x65\x2d"
> +	"\xe3\xfd\xb8\xbe\xfc\x84\x8a\xd9\x22\x22\x2e\x04\xa4\x03\x7c\x07"
> +	"\x13\xeb\x57\xa8\x1a\x23\xf0\xc7\x34\x73\xfc\x64\x6c\xea\x30\x6b"
> +	"\x4b\xcb\xc8\x86\x2f\x83\x85\xdd\xfa\x9d\x4b\x7f\xa2\xc0\x87\xe8"
> +	"\x79\x68\x33\x03\xed\x5b\xdd\x3a\x06\x2b\x3c\xf5\xb3\xa2\x78\xa6"
> +	"\x6d\x2a\x13\xf8\x3f\x44\xf8\x2d\xdf\x31\x0e\xe0\x74\xab\x6a\x36"
> +	"\x45\x97\xe8\x99\xa0\x25\x5d\xc1\x64\xf3\x1c\xc5\x08\x46\x85\x1d"
> +	"\xf9\xab\x48\x19\x5d\xed\x7e\xa1\xb1\xd5\x10\xbd\x7e\xe7\x4d\x73"
> +	"\xfa\xf3\x6b\xc3\x1e\xcf\xa2\x68\x35\x90\x46\xf4\xeb\x87\x9f\x92"
> +	"\x40\x09\x43\x8b\x48\x1c\x6c\xd7\x88\x9a\x00\x2e\xd5\xee\x38\x2b"
> +	"\xc9\x19\x0d\xa6\xfc\x02\x6e\x47\x95\x58\xe4\x47\x56\x77\xe9\xaa"
> +	"\x9e\x30\x50\xe2\x76\x56\x94\xdf\xc8\x1f\x56\xe8\x80\xb9\x6e\x71"
> +	"\x60\xc9\x80\xdd\x98\xed\xd3\xdf\xff\xff\xff\xff\xff\xff\xff\xff",
> +	},
> +#endif /* CONFIG_CRYPTO_DH_GROUPS_RFC3526 */
>   };
>   
>   /* 2 is used as a generator for all safe-prime groups. */
> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
> index 59be1fe3a978..7eb1fad93d02 100644
> --- a/include/crypto/dh.h
> +++ b/include/crypto/dh.h
> @@ -29,6 +29,13 @@ enum dh_group_id {
>   	dh_group_id_rfc7919_ffdhe6144,
>   	dh_group_id_rfc7919_ffdhe8192,
>   #endif
> +#ifdef CONFIG_CRYPTO_DH_GROUPS_RFC3526
> +	dh_group_id_rfc3526_modp2048 = 6, /* Constant used by test vector. */
> +	dh_group_id_rfc3526_modp3072,
> +	dh_group_id_rfc3526_modp4096,
> +	dh_group_id_rfc3526_modp6144,
> +	dh_group_id_rfc3526_modp8192,
> +#endif
>   };
>   
>   /**
> 
Again the comment about enums in uppercase.

Otherwise looks good.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 07/18] crypto: testmgr - add DH RFC 3526 modp2048 test vector

[Nicolai Stange]

The previous patch introduced support for the safe-prime groups specified
by RFC 3526. In order to test this functionality, add a corresponding test
vector to testmgr. The test data has been generated with OpenSSL.

Note that this new entry provides test coverage for the recent change to
crypto_dh_encode_key(), which made it to skip the serialization of domain
parameters for known groups, i.e. those with
->group_id != dh_group_id_unknown.

Moreover, a future patch will make the DH implementation to reject domain
parameters not corresponding to some safe-prime group approved by
SP800-56Arev3 in FIPS mode and the existing DH test vectors don't qualify.
So this patch here will ensure that there's still some suitable test vector
available.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/testmgr.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index ad1450c8e1e3..d18844c7499e 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1332,6 +1332,98 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_ss_size = 256,
 	},
 #endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919) */
+#if IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
+	{
+	.secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x01" /* len */
+	"\x06\x00\x00\x00" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x01\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x01\x14" /* len */
+	"\x00\x00\x00\x06" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x00\x01\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#endif
+	/* xa */
+	"\x38\x77\xec\x02\xc5\xae\xc2\x1c\x4c\x5e\xf5\xa2\xfb\x7e\x06\xf2"
+	"\xa0\x32\x0f\x3d\xf5\xcb\x75\xd0\xd7\x47\x12\x06\xca\x11\x55\xe4"
+	"\x16\xff\x35\xd3\xda\x36\x69\x04\xc4\xd8\x63\x96\xd4\x1d\x92\x6d"
+	"\xd6\x1f\x4b\x22\x7f\xa8\x68\xae\x53\x46\x49\x5a\x06\xfd\x33\xb9"
+	"\x47\x7b\x2c\xaf\x5f\x52\x76\x2d\xe5\x46\x44\xd7\xf1\x5e\xdf\xaa"
+	"\x17\xb5\x3c\x86\x5e\x69\xf9\xf5\x4a\x86\xc6\x58\x77\x81\x88\x78"
+	"\x7d\x5b\xf6\xe3\xd7\x46\x4c\xaf\x75\xf8\x53\x76\xf6\xcc\x6d\xd2"
+	"\x8e\xb7\x0f\x4c\xea\x3e\x82\x55\x82\x34\x5c\x99\x32\x7c\x22\x4b"
+	"\xcc\xd7\xfd\x39\x72\x64\x27\xc6\x5a\x10\xc2\x97\x38\x20\x51\xd2"
+	"\xf3\xf0\x95\xe7\xe4\xfb\x5a\x1e\xb6\x08\x81\xda\xac\x7e\xdf\x85"
+	"\xad\xa5\xdb\xd1\x96\xc6\xab\x9c\x9b\x8e\xa5\x80\x0a\xf0\xce\xf6"
+	"\x60\xb2\x88\xc1\x3a\x77\xb3\x87\xd1\x39\x68\x56\x7b\x8c\x8a\xb4"
+	"\xb5\x35\xd6\x93\xdf\x8e\x43\x3c\x41\xb5\xb5\x5d\xdd\xd2\x36\x93"
+	"\xa3\x09\xeb\x9f\x6c\x13\xac\xcb\xa0\x50\x4e\x7c\x49\x20\xcf\xf7"
+	"\xa6\xfc\xd1\x1d\x50\x72\xdf\x76\x24\xc5\xb9\xb3\x68\x1d\xe2\xdd"
+	"\xd1\xcb\x1b\x53\x2c\xed\x75\xfc\xeb\x36\x20\x9d\x82\xca\xe5\xa7",
+	.b_public =
+	"\x75\x98\x23\x19\xc9\xc2\xe1\x59\x73\xc2\x1d\xc5\x2c\xad\x22\x90"
+	"\xa8\xa4\xb4\xfa\xd7\x67\x5b\xe9\xa1\x0e\x15\x3b\x5d\xae\xd3\x25"
+	"\x29\xfc\x26\x79\xd6\x86\xf2\x21\x20\x86\xd7\x17\xce\xe7\x6a\x74"
+	"\x3e\x2e\x8b\x62\x87\x62\xe9\x27\xc0\x57\xca\x5b\xaf\x86\x22\xd6"
+	"\xdd\xf6\x88\xd2\x86\x21\xf7\x39\x6a\x3f\x52\x17\x03\xdc\xb9\x44"
+	"\x03\xdf\xb5\x6e\x5d\x15\x50\x6f\xf8\x9a\x3c\xee\x9f\xc5\x01\x23"
+	"\xd8\x2d\xb8\x18\x37\xc8\xed\x7d\x46\x27\x03\xc9\xae\x3b\xbf\x9e"
+	"\x4e\x98\x91\x30\x56\xcb\x09\x6b\x8e\xd3\xe5\x87\xfe\x82\x66\x36"
+	"\x2c\xee\x88\x74\x00\x8a\x2d\x36\x39\x2b\xe7\xbd\x18\x21\x36\xd0"
+	"\x98\x34\x6c\xb1\x4f\xbf\xd0\x0c\xd3\x6c\x64\x2e\x04\xfa\x68\x13"
+	"\x51\xaf\x1b\xc8\xc3\xbd\x13\x44\x72\x89\xd5\xa3\xd8\x83\x22\xf1"
+	"\x92\xeb\x5a\x70\x5e\x91\x1e\x86\xb9\x2f\x18\x44\x8c\x5a\xe0\x18"
+	"\x6c\x7a\xc6\x20\x27\x27\xae\x6a\x9e\x1b\x9b\xae\x13\xc9\x73\x22"
+	"\x0c\x0d\xdf\x97\x9c\x87\x06\x48\xdc\xe0\x8d\x83\xe1\x32\x8a\x8f"
+	"\x80\x60\x70\x7c\x7e\x10\x10\xf0\xd7\x49\x09\xfc\xf0\x0e\x11\x3f"
+	"\xb4\x5a\x9e\x3d\x38\x28\x3d\x46\x5a\x63\x6c\x9e\x14\xe3\x7c\x13",
+	.expected_a_public =
+	"\xca\x88\x57\x90\x69\x2d\x30\x40\xbc\x97\xd0\x79\x4b\x9e\x8c\x3c"
+	"\x55\x78\x01\x81\x0c\x62\xa3\x51\x80\xcb\x83\x56\x70\x50\xe8\x41"
+	"\x2d\x72\x0c\x7a\x1d\x9b\xf7\x0d\xe6\x81\x2b\x51\xca\xf7\x6c\xf0"
+	"\x45\x92\x9d\x7e\x3c\xe3\x22\xbc\x16\x5a\x2f\x92\x79\xbe\xea\xbe"
+	"\xa5\x73\xf7\xfa\xbf\x86\x71\x9b\x28\x4f\x32\x86\x44\xdb\xc4\x0f"
+	"\xb6\x30\xdd\x95\xa5\xcb\xa8\x16\x96\x76\x51\x27\xfb\x6e\xc1\x06"
+	"\x19\x28\x8a\xf0\x3d\x92\xe8\x6b\x57\x2a\xfc\x63\x96\xea\xf0\x9b"
+	"\x4e\xbe\xeb\x42\x38\x66\x0d\x47\x6b\xc6\x2b\xb1\xe6\x49\xe4\x82"
+	"\xcf\x74\xb4\x5a\x13\x7b\xaf\x22\x53\x34\x5b\xf2\x6f\xda\x5e\x51"
+	"\x00\xd1\x37\x9d\x9c\x8b\x3e\xe9\x05\x37\x8d\x01\xb9\x64\x06\xdd"
+	"\xee\x10\xa2\x96\xa1\x18\xbf\xb8\xb5\x77\x24\xda\xb0\x7f\x07\x7e"
+	"\x98\xf4\xeb\x0e\x80\x39\x54\x1e\x7e\xf6\x5c\x6b\x02\xf5\x91\x5e"
+	"\x3e\xb2\xa5\xe0\x13\x25\x9b\x04\xf9\xb3\x42\x82\xfe\x6a\x11\x94"
+	"\x4b\x01\x35\x43\xb5\x32\x20\x6e\xc0\x91\xad\x1e\xbe\xdf\xb6\x11"
+	"\x5c\x91\x83\x66\xa0\xe5\x27\x82\x7d\x45\xa8\x70\xa1\x37\xcd\x24"
+	"\xab\xb3\xb5\x13\x97\x61\x72\x7b\x03\x58\x06\xd9\x90\x78\x3c\xd1",
+	.expected_ss =
+	"\xba\x1e\x8c\x44\x39\x9e\xab\xe4\xe2\x75\xae\x54\xe3\xa9\xde\xb8"
+	"\x21\x3f\x46\x54\xb8\xea\xe7\xe3\xd6\x1e\xd0\xf3\x33\x2c\xb9\xb7"
+	"\xbd\x76\x63\xf1\xec\x2e\xf9\xe7\x3b\xa4\xa8\x94\xba\x9b\x34\x1b"
+	"\xfc\xa8\xbd\x89\xd2\x11\xb1\xa0\x02\x76\xe1\xb3\xe9\x89\x63\xc0"
+	"\xc2\xda\x77\x53\xc5\x53\x2d\x1d\x0e\xa5\x14\xac\xf1\x91\xfa\x5b"
+	"\x52\x8e\xeb\x73\x54\x7f\x99\xa6\x39\x17\x32\xcc\x4d\x59\x3a\x4c"
+	"\xd7\xea\xb3\x70\x84\xb4\x04\xb8\xb2\xcd\x77\x6e\x2b\xa1\xc6\xeb"
+	"\xa1\x2e\x0c\x8f\xaa\xd1\x83\xe5\x66\x12\x2c\x99\x72\x52\x2a\xfd"
+	"\x67\x0d\x14\xd7\x11\xd3\xf1\x77\x5f\x86\x06\x21\xcb\x7a\x14\x78"
+	"\x94\x6f\x42\xe9\xa9\xf4\x22\x8e\x94\x6a\x74\xfb\x13\x30\xd3\x41"
+	"\xde\xd3\xac\x36\x88\xc9\x24\xe6\x55\x20\x79\xfb\xd7\x81\x6a\xac"
+	"\x3b\x91\xcb\x34\x33\xb8\x61\x86\xf6\x2c\x88\x14\xe7\x64\x23\xaf"
+	"\x05\x34\x31\x9a\x56\x1e\xe5\xd5\xb6\xe6\x79\xd0\x2d\xcf\x4c\x41"
+	"\x95\x16\x08\xa8\x2c\xdd\x7a\xde\xe0\x77\x10\x71\x9b\x98\xfc\xc1"
+	"\x2c\x48\xd4\xfa\x54\x45\x44\xed\x7f\x42\x92\x63\x9c\xf6\x81\x7f"
+	"\xe0\x66\x55\x6e\x69\xa5\x52\x0b\x4d\x86\x06\x85\xb2\xb0\x7e\x47",
+	.secret_size = 276,
+	.b_public_size = 256,
+	.expected_a_public_size = 256,
+	.expected_ss_size = 256,
+	},
+#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526) */
 	{
 	.secret =
 #ifdef __LITTLE_ENDIAN
-- 
2.26.2

Re: [PATCH 07/18] crypto: testmgr - add DH RFC 3526 modp2048 test vector

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> The previous patch introduced support for the safe-prime groups specified
> by RFC 3526. In order to test this functionality, add a corresponding test
> vector to testmgr. The test data has been generated with OpenSSL.
> 
> Note that this new entry provides test coverage for the recent change to
> crypto_dh_encode_key(), which made it to skip the serialization of domain
> parameters for known groups, i.e. those with
> ->group_id != dh_group_id_unknown.
> 
> Moreover, a future patch will make the DH implementation to reject domain
> parameters not corresponding to some safe-prime group approved by
> SP800-56Arev3 in FIPS mode and the existing DH test vectors don't qualify.
> So this patch here will ensure that there's still some suitable test vector
> available.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/testmgr.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 92 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 08/18] crypto: testmgr - run only subset of DH vectors based on config

[Nicolai Stange]

With the previous patches, the testmgr now has up to four test vectors for
DH which all test more or less the same thing:
- the two vectors from before this series,
- the vector for the ffdhe2048 group, enabled if
  CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set and
- the vector for the modp2048 group, similarly enabled if
  CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set.

In order to avoid too much redundancy during DH testing, enable only a
subset of these depending on the kernel config:
- if CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set, enable only the ffdhe2048
  vector,
- otherwise, if CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set, enable only
  the modp2048 vector and
- only enable the original two vectors if neither of these options
  has been selected.

Note that an upcoming patch will make the DH implementation to reject any
domain parameters not corresponding to some safe-prime group approved by
SP800-56Arev3 in FIPS mode. Thus, having CONFIG_FIPS enabled, but
both of CONFIG_CRYPTO_DH_GROUPS_RFC7919 and
CONFIG_CRYPTO_DH_GROUPS_RFC3526 unset wouldn't make much sense as it would
render the DH implementation unusable in FIPS mode. Conversely, any
reasonable configuration would ensure that the original, non-conforming
test vectors would not get to run in FIPS mode.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/testmgr.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index d18844c7499e..b295512c8f22 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1331,8 +1331,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
 	},
-#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919) */
-#if IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
+#elif IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
 	{
 	.secret =
 #ifdef __LITTLE_ENDIAN
@@ -1423,7 +1422,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
 	},
-#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526) */
+#else
 	{
 	.secret =
 #ifdef __LITTLE_ENDIAN
@@ -1642,6 +1641,7 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
 	},
+#endif
 };
 
 static const struct kpp_testvec curve25519_tv_template[] = {
-- 
2.26.2

Re: [PATCH 08/18] crypto: testmgr - run only subset of DH vectors based on config

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> With the previous patches, the testmgr now has up to four test vectors for
> DH which all test more or less the same thing:
> - the two vectors from before this series,
> - the vector for the ffdhe2048 group, enabled if
>    CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set and
> - the vector for the modp2048 group, similarly enabled if
>    CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set.
> 
> In order to avoid too much redundancy during DH testing, enable only a
> subset of these depending on the kernel config:
> - if CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set, enable only the ffdhe2048
>    vector,
> - otherwise, if CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set, enable only
>    the modp2048 vector and
> - only enable the original two vectors if neither of these options
>    has been selected.
> 
> Note that an upcoming patch will make the DH implementation to reject any
> domain parameters not corresponding to some safe-prime group approved by
> SP800-56Arev3 in FIPS mode. Thus, having CONFIG_FIPS enabled, but
> both of CONFIG_CRYPTO_DH_GROUPS_RFC7919 and
> CONFIG_CRYPTO_DH_GROUPS_RFC3526 unset wouldn't make much sense as it would
> render the DH implementation unusable in FIPS mode. Conversely, any
> reasonable configuration would ensure that the original, non-conforming
> test vectors would not get to run in FIPS mode.
> 

For some weird reason the NVMe spec mandates for its TLS profile the 
ffdhe3072 group, so I would prefer if you would be using that as the 
default group for testing.

> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/testmgr.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/crypto/testmgr.h b/crypto/testmgr.h
> index d18844c7499e..b295512c8f22 100644
> --- a/crypto/testmgr.h
> +++ b/crypto/testmgr.h
> @@ -1331,8 +1331,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	.expected_a_public_size = 256,
>   	.expected_ss_size = 256,
>   	},
> -#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919) */
> -#if IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
> +#elif IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
>   	{
>   	.secret =
>   #ifdef __LITTLE_ENDIAN
> @@ -1423,7 +1422,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	.expected_a_public_size = 256,
>   	.expected_ss_size = 256,
>   	},
> -#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526) */
> +#else
>   	{
>   	.secret =
>   #ifdef __LITTLE_ENDIAN
> @@ -1642,6 +1641,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>   	.expected_a_public_size = 256,
>   	.expected_ss_size = 256,
>   	},
> +#endif
>   };
>   
>   static const struct kpp_testvec curve25519_tv_template[] = {
> 
... and maybe add a config option to run a full test.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 08/18] crypto: testmgr - run only subset of DH vectors based on config

[Nicolai Stange]

Hannes Reinecke <hare@suse.de> writes:

> On 12/1/21 1:48 AM, Nicolai Stange wrote:
>> With the previous patches, the testmgr now has up to four test vectors for
>> DH which all test more or less the same thing:
>> - the two vectors from before this series,
>> - the vector for the ffdhe2048 group, enabled if
>>    CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set and
>> - the vector for the modp2048 group, similarly enabled if
>>    CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set.
>>
>> In order to avoid too much redundancy during DH testing, enable only a
>> subset of these depending on the kernel config:
>> - if CONFIG_CRYPTO_DH_GROUPS_RFC7919 is set, enable only the ffdhe2048
>>    vector,
>> - otherwise, if CONFIG_CRYPTO_DH_GROUPS_RFC3526 is set, enable only
>>    the modp2048 vector and
>> - only enable the original two vectors if neither of these options
>>    has been selected.
>>
>> Note that an upcoming patch will make the DH implementation to reject any
>> domain parameters not corresponding to some safe-prime group approved by
>> SP800-56Arev3 in FIPS mode. Thus, having CONFIG_FIPS enabled, but
>> both of CONFIG_CRYPTO_DH_GROUPS_RFC7919 and
>> CONFIG_CRYPTO_DH_GROUPS_RFC3526 unset wouldn't make much sense as it would
>> render the DH implementation unusable in FIPS mode. Conversely, any
>> reasonable configuration would ensure that the original, non-conforming
>> test vectors would not get to run in FIPS mode.
>>
>
> For some weird reason the NVMe spec mandates for its TLS profile the
> ffdhe3072 group, so I would prefer if you would be using that as the
> default group for testing.

Done for v2.

>
>> Signed-off-by: Nicolai Stange <nstange@suse.de>
>> ---
>>   crypto/testmgr.h | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>> index d18844c7499e..b295512c8f22 100644
>> --- a/crypto/testmgr.h
>> +++ b/crypto/testmgr.h
>> @@ -1331,8 +1331,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>>   	.expected_a_public_size = 256,
>>   	.expected_ss_size = 256,
>>   	},
>> -#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC7919) */
>> -#if IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
>> +#elif IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
>>   	{
>>   	.secret =
>>   #ifdef __LITTLE_ENDIAN
>> @@ -1423,7 +1422,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>>   	.expected_a_public_size = 256,
>>   	.expected_ss_size = 256,
>>   	},
>> -#endif /* IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526) */
>> +#else
>>   	{
>>   	.secret =
>>   #ifdef __LITTLE_ENDIAN
>> @@ -1642,6 +1641,7 @@ static const struct kpp_testvec dh_tv_template[] = {
>>   	.expected_a_public_size = 256,
>>   	.expected_ss_size = 256,
>>   	},
>> +#endif
>>   };
>>     static const struct kpp_testvec curve25519_tv_template[] = {
>>
> ... and maybe add a config option to run a full test.

I didn't do this at this point, because I don't see much value in
running tests on more than one randomly selected DH group, i.e. on
ffdhe3072 and modp2048: both test vectors test the same code paths.

It might perhaps make sense to run tests for all the DH safe-prime
groups each for verifying that the resp. ->p primes are all correct. But
that would be a large TV dump and I'm not sure it would be desirable...

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

[PATCH 09/18] crypto: dh - implement private key generation primitive

[Nicolai Stange]

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@suse.de>
---
 crypto/Kconfig      |   1 +
 crypto/dh_helper.c  | 128 ++++++++++++++++++++++++++++++++++++++++++++
 include/crypto/dh.h |  22 ++++++++
 3 files changed, 151 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index fcb044bdc90a..578711b02bb3 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -228,6 +228,7 @@ menuconfig CRYPTO_DH
 	tristate "Diffie-Hellman algorithm"
 	select CRYPTO_KPP
 	select MPILIB
+	select CRYPTO_RNG_DEFAULT
 	help
 	  Generic implementation of the Diffie-Hellman algorithm.
 
diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index fb8df4734dc1..5a8c9c50297f 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -9,6 +9,7 @@
 #include <linux/string.h>
 #include <crypto/dh.h>
 #include <crypto/kpp.h>
+#include <crypto/rng.h>
 
 #define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
 				sizeof(enum dh_group_id) + 3 * sizeof(int))
@@ -592,3 +593,130 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
+
+static u64 __add_u64_to_be(__be64 *dst, unsigned int n, u64 val)
+{
+	unsigned int i;
+
+	for (i = n; val && i > 0; --i) {
+		u64 tmp = be64_to_cpu(dst[i - 1]);
+
+		tmp += val;
+		val = tmp >= val ? 0 : 1;
+		dst[i - 1] = cpu_to_be64(tmp);
+	}
+
+	return val;
+}
+
+int crypto_dh_gen_privkey(enum dh_group_id group_id,
+			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
+			  unsigned int *key_size)
+{
+	const struct safe_prime_group *g;
+	unsigned int n, tmp_size;
+	__be64 *tmp;
+	int err;
+	u64 h, o;
+
+	/*
+	 * Generate a private key following NIST SP800-56Ar3,
+	 * sec. 5.6.1.1.1 and 5.6.1.1.3 resp.. This is supported only
+	 * for the (approved) safe-prime groups.
+	 */
+	g = get_safe_prime_group(group_id);
+	if (!g)
+		return -EINVAL;
+
+	/*
+	 * 5.6.1.1.1: choose key length N such that
+	 * 2 * ->max_strength <= N <= log2(q) + 1 = ->p_size * 8 - 1
+	 * with q = (p - 1) / 2 for the safe-prime groups.
+	 * Choose the lower bound's next power of two for N in order to
+	 * avoid excessively large private keys while still
+	 * maintaining some extra reserve beyond the bare minimum in
+	 * most cases. Note that for each entry in safe_prime_groups[],
+	 * the following holds for such N:
+	 * - N >= 256, in particular it is a multiple of 2^6 = 64
+	 *   bits and
+	 * - N < log2(q) + 1, i.e. N respects the upper bound.
+	 */
+	n = roundup_pow_of_two(2 * g->max_strength);
+	WARN_ON_ONCE(n & ((1u << 6) - 1));
+	n >>= 6; /* Convert N into units of u64. */
+
+	/*
+	 * Reserve one extra u64 to hold the extra random bits
+	 * required as per 5.6.1.1.3.
+	 */
+	tmp_size = (n + 1) * sizeof(__be64);
+	tmp = kmalloc(tmp_size, GFP_KERNEL);
+	if (!tmp)
+		return -ENOMEM;
+
+	/*
+	 * 5.6.1.1.3, step 3 (and implicitly step 4): obtain N + 64
+	 * random bits and interpret them as a big endian integer.
+	 */
+	err = -EFAULT;
+	if (crypto_get_default_rng())
+		goto out;
+
+	err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)tmp, tmp_size);
+	crypto_put_default_rng();
+	if (err)
+		goto out;
+
+	/*
+	 * 5.6.1.1.3, step 5 is implicit: 2^N < q and thus,
+	 * M = min(2^N, q) = 2^N.
+	 *
+	 * For step 6, calculate
+	 * key = (tmp[] mod (M - 1)) + 1 = (tmp[] mod (2^N - 1)) + 1.
+	 *
+	 * In order to avoid expensive divisions, note that
+	 * 2^N mod (2^N - 1) = 1 and thus, for any integer h,
+	 * 2^N * h mod (2^N - 1) = h mod (2^N - 1) always holds.
+	 * The big endian integer tmp[] composed of n + 1 64bit words
+	 * may be written as tmp[] = h * 2^N + l, with h = tmp[0]
+	 * representing the 64 most significant bits and l
+	 * corresponding to the remaining 2^N bits. With the remark
+	 * from above,
+	 * h * 2^N + l mod (2^N - 1) = l + h mod (2^N - 1).
+	 * As both, l and h are less than 2^N, their sum after
+	 * this first reduction is guaranteed to be <= 2^(N + 1) - 2.
+	 * Or equivalently, that their sum can again be written as
+	 * h' * 2^N + l' with h' now either zero or one and if one,
+	 * then l' <= 2^N - 2. Thus, all bits at positions >= N will
+	 * be zero after a second reduction:
+	 * h' * 2^N + l' mod (2^N - 1) = l' + h' mod (2^N - 1).
+	 * At this point, it is still possible that
+	 * l' + h' = 2^N - 1, i.e. that l' + h' mod (2^N - 1)
+	 * is zero. This condition will be detected below by means of
+	 * the final increment overflowing in this case.
+	 */
+	h = be64_to_cpu(tmp[0]);
+	h = __add_u64_to_be(tmp + 1, n, h);
+	h = __add_u64_to_be(tmp + 1, n, h);
+	WARN_ON_ONCE(h);
+
+	/* Increment to obtain the final result. */
+	o = __add_u64_to_be(tmp + 1, n, 1);
+	/*
+	 * The overflow bit o from the increment is either zero or
+	 * one. If zero, tmp[1:n] holds the final result in big-endian
+	 * order. If one, tmp[1:n] is zero now, but needs to be set to
+	 * one, c.f. above.
+	 */
+	if (o)
+		tmp[n] = cpu_to_be64(1);
+
+	/* n is in units of u64, convert to bytes. */
+	*key_size = n << 3;
+	memcpy(key, &tmp[1], *key_size);
+
+out:
+	kfree_sensitive(tmp);
+	return err;
+}
+EXPORT_SYMBOL_GPL(crypto_dh_gen_privkey);
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 7eb1fad93d02..182100395bbb 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -99,4 +99,26 @@ int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params);
  */
 int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params);
 
+/*
+ * The maximum key length is two times the max. sec. strength of the
+ * safe-prime groups, rounded up to the next power of two.
+ */
+#define CRYPTO_DH_MAX_PRIVKEY_SIZE (512 / 8)
+
+/**
+ * crypto_dh_gen_privkey() - generate a DH private key
+ * @buf:	The DH group to generate a key for
+ * @key:	Buffer provided by the caller to receive the generated
+ *		key
+ * @key_size:	Pointer to an unsigned integer the generated key's length
+ *		will be stored in
+ *
+ * This function is intended to generate an ephemeral DH key.
+ *
+ * Return:	Negative error code on failure, 0 on success
+ */
+int crypto_dh_gen_privkey(enum dh_group_id group_id,
+			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
+			  unsigned int *key_size);
+
 #endif
-- 
2.26.2

Re: [PATCH 09/18] crypto: dh - implement private key generation primitive

[Hannes Reinecke]

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@suse.de>
> ---
>   crypto/Kconfig      |   1 +
>   crypto/dh_helper.c  | 128 ++++++++++++++++++++++++++++++++++++++++++++
>   include/crypto/dh.h |  22 ++++++++
>   3 files changed, 151 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 09/18] crypto: dh - implement private key generation primitive

[Stephan Müller]

Am Mittwoch, 1. Dezember 2021, 01:48:49 CET schrieb Nicolai Stange:

Hi Nicolai,

> 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@suse.de>
> ---
>  crypto/Kconfig      |   1 +
>  crypto/dh_helper.c  | 128 ++++++++++++++++++++++++++++++++++++++++++++
>  include/crypto/dh.h |  22 ++++++++
>  3 files changed, 151 insertions(+)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index fcb044bdc90a..578711b02bb3 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -228,6 +228,7 @@ menuconfig CRYPTO_DH
>  	tristate "Diffie-Hellman algorithm"
>  	select CRYPTO_KPP
>  	select MPILIB
> +	select CRYPTO_RNG_DEFAULT
>  	help
>  	  Generic implementation of the Diffie-Hellman algorithm.
> 
> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
> index fb8df4734dc1..5a8c9c50297f 100644
> --- a/crypto/dh_helper.c
> +++ b/crypto/dh_helper.c
> @@ -9,6 +9,7 @@
>  #include <linux/string.h>
>  #include <crypto/dh.h>
>  #include <crypto/kpp.h>
> +#include <crypto/rng.h>
> 
>  #define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
>  				sizeof(enum dh_group_id) + 3 * sizeof(int))
> @@ -592,3 +593,130 @@ int crypto_dh_decode_key(const char *buf, unsigned int
> len, struct dh *params) return 0;
>  }
>  EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
> +
> +static u64 __add_u64_to_be(__be64 *dst, unsigned int n, u64 val)
> +{
> +	unsigned int i;
> +
> +	for (i = n; val && i > 0; --i) {
> +		u64 tmp = be64_to_cpu(dst[i - 1]);
> +
> +		tmp += val;
> +		val = tmp >= val ? 0 : 1;
> +		dst[i - 1] = cpu_to_be64(tmp);
> +	}
> +
> +	return val;
> +}
> +
> +int crypto_dh_gen_privkey(enum dh_group_id group_id,
> +			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
> +			  unsigned int *key_size)
> +{
> +	const struct safe_prime_group *g;
> +	unsigned int n, tmp_size;
> +	__be64 *tmp;
> +	int err;
> +	u64 h, o;
> +
> +	/*
> +	 * Generate a private key following NIST SP800-56Ar3,
> +	 * sec. 5.6.1.1.1 and 5.6.1.1.3 resp.. This is supported only
> +	 * for the (approved) safe-prime groups.
> +	 */
> +	g = get_safe_prime_group(group_id);
> +	if (!g)

What about

if (g == dh_group_id_unknown)

?

> +		return -EINVAL;
> +
> +	/*
> +	 * 5.6.1.1.1: choose key length N such that
> +	 * 2 * ->max_strength <= N <= log2(q) + 1 = ->p_size * 8 - 1
> +	 * with q = (p - 1) / 2 for the safe-prime groups.
> +	 * Choose the lower bound's next power of two for N in order to
> +	 * avoid excessively large private keys while still
> +	 * maintaining some extra reserve beyond the bare minimum in
> +	 * most cases. Note that for each entry in safe_prime_groups[],
> +	 * the following holds for such N:
> +	 * - N >= 256, in particular it is a multiple of 2^6 = 64
> +	 *   bits and
> +	 * - N < log2(q) + 1, i.e. N respects the upper bound.
> +	 */
> +	n = roundup_pow_of_two(2 * g->max_strength);
> +	WARN_ON_ONCE(n & ((1u << 6) - 1));
> +	n >>= 6; /* Convert N into units of u64. */

Couldn't we pre-compute that value for each of the safeprime groups? This 
value should be static for each of them.
> +
> +	/*
> +	 * Reserve one extra u64 to hold the extra random bits
> +	 * required as per 5.6.1.1.3.
> +	 */
> +	tmp_size = (n + 1) * sizeof(__be64);

Maybe add this to the pre-computed value?

> +	tmp = kmalloc(tmp_size, GFP_KERNEL);
> +	if (!tmp)
> +		return -ENOMEM;
> +
> +	/*
> +	 * 5.6.1.1.3, step 3 (and implicitly step 4): obtain N + 64
> +	 * random bits and interpret them as a big endian integer.
> +	 */
> +	err = -EFAULT;
> +	if (crypto_get_default_rng())
> +		goto out;
> +
> +	err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)tmp, tmp_size);
> +	crypto_put_default_rng();
> +	if (err)
> +		goto out;
> +
> +	/*
> +	 * 5.6.1.1.3, step 5 is implicit: 2^N < q and thus,
> +	 * M = min(2^N, q) = 2^N.
> +	 *
> +	 * For step 6, calculate
> +	 * key = (tmp[] mod (M - 1)) + 1 = (tmp[] mod (2^N - 1)) + 1.
> +	 *
> +	 * In order to avoid expensive divisions, note that
> +	 * 2^N mod (2^N - 1) = 1 and thus, for any integer h,
> +	 * 2^N * h mod (2^N - 1) = h mod (2^N - 1) always holds.
> +	 * The big endian integer tmp[] composed of n + 1 64bit words
> +	 * may be written as tmp[] = h * 2^N + l, with h = tmp[0]
> +	 * representing the 64 most significant bits and l
> +	 * corresponding to the remaining 2^N bits. With the remark
> +	 * from above,
> +	 * h * 2^N + l mod (2^N - 1) = l + h mod (2^N - 1).
> +	 * As both, l and h are less than 2^N, their sum after
> +	 * this first reduction is guaranteed to be <= 2^(N + 1) - 2.
> +	 * Or equivalently, that their sum can again be written as
> +	 * h' * 2^N + l' with h' now either zero or one and if one,
> +	 * then l' <= 2^N - 2. Thus, all bits at positions >= N will
> +	 * be zero after a second reduction:
> +	 * h' * 2^N + l' mod (2^N - 1) = l' + h' mod (2^N - 1).
> +	 * At this point, it is still possible that
> +	 * l' + h' = 2^N - 1, i.e. that l' + h' mod (2^N - 1)
> +	 * is zero. This condition will be detected below by means of
> +	 * the final increment overflowing in this case.
> +	 */
> +	h = be64_to_cpu(tmp[0]);
> +	h = __add_u64_to_be(tmp + 1, n, h);
> +	h = __add_u64_to_be(tmp + 1, n, h);
> +	WARN_ON_ONCE(h);
> +
> +	/* Increment to obtain the final result. */
> +	o = __add_u64_to_be(tmp + 1, n, 1);
> +	/*
> +	 * The overflow bit o from the increment is either zero or
> +	 * one. If zero, tmp[1:n] holds the final result in big-endian
> +	 * order. If one, tmp[1:n] is zero now, but needs to be set to
> +	 * one, c.f. above.
> +	 */
> +	if (o)
> +		tmp[n] = cpu_to_be64(1);
> +
> +	/* n is in units of u64, convert to bytes. */
> +	*key_size = n << 3;
> +	memcpy(key, &tmp[1], *key_size);
> +
> +out:
> +	kfree_sensitive(tmp);
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(crypto_dh_gen_privkey);
> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
> index 7eb1fad93d02..182100395bbb 100644
> --- a/include/crypto/dh.h
> +++ b/include/crypto/dh.h
> @@ -99,4 +99,26 @@ int crypto_dh_encode_key(char *buf, unsigned int len,
> const struct dh *params); */
>  int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh
> *params);
> 
> +/*
> + * The maximum key length is two times the max. sec. strength of the
> + * safe-prime groups, rounded up to the next power of two.
> + */
> +#define CRYPTO_DH_MAX_PRIVKEY_SIZE (512 / 8)
> +
> +/**
> + * crypto_dh_gen_privkey() - generate a DH private key
> + * @buf:	The DH group to generate a key for
> + * @key:	Buffer provided by the caller to receive the generated
> + *		key
> + * @key_size:	Pointer to an unsigned integer the generated key's length
> + *		will be stored in
> + *
> + * This function is intended to generate an ephemeral DH key.
> + *
> + * Return:	Negative error code on failure, 0 on success
> + */
> +int crypto_dh_gen_privkey(enum dh_group_id group_id,
> +			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
> +			  unsigned int *key_size);
> +
>  #endif


Ciao
Stephan

Re: [PATCH 09/18] crypto: dh - implement private key generation primitive

[Nicolai Stange]

Hi Stephan,

first of all, many thanks for your review!

Stephan Müller <smueller@chronox.de> writes:

> Am Mittwoch, 1. Dezember 2021, 01:48:49 CET schrieb Nicolai Stange:
>
>> 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@suse.de>
>> ---
>>  crypto/Kconfig      |   1 +
>>  crypto/dh_helper.c  | 128 ++++++++++++++++++++++++++++++++++++++++++++
>>  include/crypto/dh.h |  22 ++++++++
>>  3 files changed, 151 insertions(+)
>> 
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index fcb044bdc90a..578711b02bb3 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -228,6 +228,7 @@ menuconfig CRYPTO_DH
>>  	tristate "Diffie-Hellman algorithm"
>>  	select CRYPTO_KPP
>>  	select MPILIB
>> +	select CRYPTO_RNG_DEFAULT
>>  	help
>>  	  Generic implementation of the Diffie-Hellman algorithm.
>> 
>> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
>> index fb8df4734dc1..5a8c9c50297f 100644
>> --- a/crypto/dh_helper.c
>> +++ b/crypto/dh_helper.c
>> @@ -9,6 +9,7 @@
>>  #include <linux/string.h>
>>  #include <crypto/dh.h>
>>  #include <crypto/kpp.h>
>> +#include <crypto/rng.h>
>> 
>>  #define DH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + \
>>  				sizeof(enum dh_group_id) + 3 * sizeof(int))
>> @@ -592,3 +593,130 @@ int crypto_dh_decode_key(const char *buf, unsigned int
>> len, struct dh *params) return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
>> +
>> +static u64 __add_u64_to_be(__be64 *dst, unsigned int n, u64 val)
>> +{
>> +	unsigned int i;
>> +
>> +	for (i = n; val && i > 0; --i) {
>> +		u64 tmp = be64_to_cpu(dst[i - 1]);
>> +
>> +		tmp += val;
>> +		val = tmp >= val ? 0 : 1;
>> +		dst[i - 1] = cpu_to_be64(tmp);
>> +	}
>> +
>> +	return val;
>> +}
>> +
>> +int crypto_dh_gen_privkey(enum dh_group_id group_id,
>> +			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
>> +			  unsigned int *key_size)
>> +{
>> +	const struct safe_prime_group *g;
>> +	unsigned int n, tmp_size;
>> +	__be64 *tmp;
>> +	int err;
>> +	u64 h, o;
>> +
>> +	/*
>> +	 * Generate a private key following NIST SP800-56Ar3,
>> +	 * sec. 5.6.1.1.1 and 5.6.1.1.3 resp.. This is supported only
>> +	 * for the (approved) safe-prime groups.
>> +	 */
>> +	g = get_safe_prime_group(group_id);
>> +	if (!g)
>
> What about
>
> if (g == dh_group_id_unknown)
>
> ?

No, I think this is correct: get_safe_prime_group() returns a pointer to
a struct safe_prime_group instances looked up from the
safe_prime_groups[] array and for dh_group_id_unknown NULL is returned.


>
>> +		return -EINVAL;
>> +
>> +	/*
>> +	 * 5.6.1.1.1: choose key length N such that
>> +	 * 2 * ->max_strength <= N <= log2(q) + 1 = ->p_size * 8 - 1
>> +	 * with q = (p - 1) / 2 for the safe-prime groups.
>> +	 * Choose the lower bound's next power of two for N in order to
>> +	 * avoid excessively large private keys while still
>> +	 * maintaining some extra reserve beyond the bare minimum in
>> +	 * most cases. Note that for each entry in safe_prime_groups[],
>> +	 * the following holds for such N:
>> +	 * - N >= 256, in particular it is a multiple of 2^6 = 64
>> +	 *   bits and
>> +	 * - N < log2(q) + 1, i.e. N respects the upper bound.
>> +	 */
>> +	n = roundup_pow_of_two(2 * g->max_strength);
>> +	WARN_ON_ONCE(n & ((1u << 6) - 1));
>> +	n >>= 6; /* Convert N into units of u64. */
>
> Couldn't we pre-compute that value for each of the safeprime groups? This 
> value should be static for each of them.

Can you elaborate why this would be better? As long as the value
calculated above is considered reasonable for every usecase, I don't see
the advantage of storing it somewhere.

OTOH, calculating the value on the fly
- enforces conformance to 5.6.1.1.1 (>= twice the sec strength)
- and guarantees that it is a multiple of 64 bits, as required
  by the implementation,
whereas you'd had to examine each and every individual group's setting
for correctness when storing precomputed values alongside the other,
"primary" group parameters.

Thanks,

Nicolai

>> +
>> +	/*
>> +	 * Reserve one extra u64 to hold the extra random bits
>> +	 * required as per 5.6.1.1.3.
>> +	 */
>> +	tmp_size = (n + 1) * sizeof(__be64);
>
> Maybe add this to the pre-computed value?
>
>
>> +	tmp = kmalloc(tmp_size, GFP_KERNEL);
>> +	if (!tmp)
>> +		return -ENOMEM;
>> +
>> +	/*
>> +	 * 5.6.1.1.3, step 3 (and implicitly step 4): obtain N + 64
>> +	 * random bits and interpret them as a big endian integer.
>> +	 */
>> +	err = -EFAULT;
>> +	if (crypto_get_default_rng())
>> +		goto out;
>> +
>> +	err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)tmp, tmp_size);
>> +	crypto_put_default_rng();
>> +	if (err)
>> +		goto out;
>> +
>> +	/*
>> +	 * 5.6.1.1.3, step 5 is implicit: 2^N < q and thus,
>> +	 * M = min(2^N, q) = 2^N.
>> +	 *
>> +	 * For step 6, calculate
>> +	 * key = (tmp[] mod (M - 1)) + 1 = (tmp[] mod (2^N - 1)) + 1.
>> +	 *
>> +	 * In order to avoid expensive divisions, note that
>> +	 * 2^N mod (2^N - 1) = 1 and thus, for any integer h,
>> +	 * 2^N * h mod (2^N - 1) = h mod (2^N - 1) always holds.
>> +	 * The big endian integer tmp[] composed of n + 1 64bit words
>> +	 * may be written as tmp[] = h * 2^N + l, with h = tmp[0]
>> +	 * representing the 64 most significant bits and l
>> +	 * corresponding to the remaining 2^N bits. With the remark
>> +	 * from above,
>> +	 * h * 2^N + l mod (2^N - 1) = l + h mod (2^N - 1).
>> +	 * As both, l and h are less than 2^N, their sum after
>> +	 * this first reduction is guaranteed to be <= 2^(N + 1) - 2.
>> +	 * Or equivalently, that their sum can again be written as
>> +	 * h' * 2^N + l' with h' now either zero or one and if one,
>> +	 * then l' <= 2^N - 2. Thus, all bits at positions >= N will
>> +	 * be zero after a second reduction:
>> +	 * h' * 2^N + l' mod (2^N - 1) = l' + h' mod (2^N - 1).
>> +	 * At this point, it is still possible that
>> +	 * l' + h' = 2^N - 1, i.e. that l' + h' mod (2^N - 1)
>> +	 * is zero. This condition will be detected below by means of
>> +	 * the final increment overflowing in this case.
>> +	 */
>> +	h = be64_to_cpu(tmp[0]);
>> +	h = __add_u64_to_be(tmp + 1, n, h);
>> +	h = __add_u64_to_be(tmp + 1, n, h);
>> +	WARN_ON_ONCE(h);
>> +
>> +	/* Increment to obtain the final result. */
>> +	o = __add_u64_to_be(tmp + 1, n, 1);
>> +	/*
>> +	 * The overflow bit o from the increment is either zero or
>> +	 * one. If zero, tmp[1:n] holds the final result in big-endian
>> +	 * order. If one, tmp[1:n] is zero now, but needs to be set to
>> +	 * one, c.f. above.
>> +	 */
>> +	if (o)
>> +		tmp[n] = cpu_to_be64(1);
>> +
>> +	/* n is in units of u64, convert to bytes. */
>> +	*key_size = n << 3;
>> +	memcpy(key, &tmp[1], *key_size);
>> +
>> +out:
>> +	kfree_sensitive(tmp);
>> +	return err;
>> +}
>> +EXPORT_SYMBOL_GPL(crypto_dh_gen_privkey);
>> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
>> index 7eb1fad93d02..182100395bbb 100644
>> --- a/include/crypto/dh.h
>> +++ b/include/crypto/dh.h
>> @@ -99,4 +99,26 @@ int crypto_dh_encode_key(char *buf, unsigned int len,
>> const struct dh *params); */
>>  int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh
>> *params);
>> 
>> +/*
>> + * The maximum key length is two times the max. sec. strength of the
>> + * safe-prime groups, rounded up to the next power of two.
>> + */
>> +#define CRYPTO_DH_MAX_PRIVKEY_SIZE (512 / 8)
>> +
>> +/**
>> + * crypto_dh_gen_privkey() - generate a DH private key
>> + * @buf:	The DH group to generate a key for
>> + * @key:	Buffer provided by the caller to receive the generated
>> + *		key
>> + * @key_size:	Pointer to an unsigned integer the generated key's length
>> + *		will be stored in
>> + *
>> + * This function is intended to generate an ephemeral DH key.
>> + *
>> + * Return:	Negative error code on failure, 0 on success
>> + */
>> +int crypto_dh_gen_privkey(enum dh_group_id group_id,
>> +			  char key[CRYPTO_DH_MAX_PRIVKEY_SIZE],
>> +			  unsigned int *key_size);
>> +
>>  #endif

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

Re: [PATCH 09/18] crypto: dh - implement private key generation primitive

[Stephan Mueller]

Am Mittwoch, 8. Dezember 2021, 07:20:43 CET schrieb Nicolai Stange:

Hi Nicolai,

> >> +		return -EINVAL;
> >> +
> >> +	/*
> >> +	 * 5.6.1.1.1: choose key length N such that
> >> +	 * 2 * ->max_strength <= N <= log2(q) + 1 = ->p_size * 8 - 1
> >> +	 * with q = (p - 1) / 2 for the safe-prime groups.
> >> +	 * Choose the lower bound's next power of two for N in order to
> >> +	 * avoid excessively large private keys while still
> >> +	 * maintaining some extra reserve beyond the bare minimum in
> >> +	 * most cases. Note that for each entry in safe_prime_groups[],
> >> +	 * the following holds for such N:
> >> +	 * - N >= 256, in particular it is a multiple of 2^6 = 64
> >> +	 *   bits and
> >> +	 * - N < log2(q) + 1, i.e. N respects the upper bound.
> >> +	 */
> >> +	n = roundup_pow_of_two(2 * g->max_strength);
> >> +	WARN_ON_ONCE(n & ((1u << 6) - 1));
> >> +	n >>= 6; /* Convert N into units of u64. */
> > 
> > Couldn't we pre-compute that value for each of the safeprime groups? This
> > value should be static for each of them.
> 
> Can you elaborate why this would be better? As long as the value
> calculated above is considered reasonable for every usecase, I don't see
> the advantage of storing it somewhere.

Well, I usually try to avoid using CPU resources if I have information a-
priori. And as we have only known domain parameters in this code path, I 
thought we can spare a few CPU cycles.

> 
> OTOH, calculating the value on the fly
> - enforces conformance to 5.6.1.1.1 (>= twice the sec strength)
> - and guarantees that it is a multiple of 64 bits, as required
>   by the implementation,
> whereas you'd had to examine each and every individual group's setting
> for correctness when storing precomputed values alongside the other,
> "primary" group parameters.

You are right, but when we reach this code path we only have well-known 
parameters. Hence my suggestion.

Ciao
Stephan

[PATCH 10/18] crypto: dh - introduce support for ephemeral key generation to dh-generic

[Nicolai Stange]

The support for NVME in-band authentication currently in the works ([1])
needs to generate ephemeral DH keys. Make dh-generic's ->set_secret()
to generate an ephemeral key via the recently added crypto_dh_gen_privkey()
in case the input ->key_size is zero. Note that this behaviour is in
analogy to ecdh's ->set_secret().

[1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/crypto/dh.c b/crypto/dh.c
index 131b80064cb1..2e49b114e038 100644
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -71,25 +71,41 @@ static int dh_set_secret(struct crypto_kpp *tfm, const void *buf,
 {
 	struct dh_ctx *ctx = dh_get_ctx(tfm);
 	struct dh params;
+	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
+	int err;
 
 	/* Free the old MPI key if any */
 	dh_clear_ctx(ctx);
 
-	if (crypto_dh_decode_key(buf, len, &params) < 0)
+	err = crypto_dh_decode_key(buf, len, &params);
+	if (err)
 		goto err_clear_ctx;
 
-	if (dh_set_params(ctx, &params) < 0)
+	if (!params.key_size) {
+		err = crypto_dh_gen_privkey(params.group_id, key,
+					    &params.key_size);
+		if (err)
+			goto err_clear_ctx;
+		params.key = key;
+	}
+
+	err = dh_set_params(ctx, &params);
+	if (err)
 		goto err_clear_ctx;
 
 	ctx->xa = mpi_read_raw_data(params.key, params.key_size);
-	if (!ctx->xa)
+	if (!ctx->xa) {
+		err = -EINVAL;
 		goto err_clear_ctx;
+	}
+
+	memzero_explicit(key, sizeof(key));
 
 	return 0;
 
 err_clear_ctx:
 	dh_clear_ctx(ctx);
-	return -EINVAL;
+	return err;
 }
 
 /*
-- 
2.26.2

Re: [PATCH 10/18] crypto: dh - introduce support for ephemeral key generation to dh-generic

[Hannes Reinecke]

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. Make dh-generic's ->set_secret()
> to generate an ephemeral key via the recently added crypto_dh_gen_privkey()
> in case the input ->key_size is zero. Note that this behaviour is in
> analogy to ecdh's ->set_secret().
> 
> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh.c | 24 ++++++++++++++++++++----
>   1 file changed, 20 insertions(+), 4 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 10/18] crypto: dh - introduce support for ephemeral key generation to dh-generic

[Stephan Müller]

Am Mittwoch, 1. Dezember 2021, 01:48:50 CET schrieb Nicolai Stange:

Hi Nicolai,

> The support for NVME in-band authentication currently in the works ([1])
> needs to generate ephemeral DH keys. Make dh-generic's ->set_secret()
> to generate an ephemeral key via the recently added crypto_dh_gen_privkey()
> in case the input ->key_size is zero. Note that this behaviour is in
> analogy to ecdh's ->set_secret().
> 
> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>  crypto/dh.c | 24 ++++++++++++++++++++----
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/crypto/dh.c b/crypto/dh.c
> index 131b80064cb1..2e49b114e038 100644
> --- a/crypto/dh.c
> +++ b/crypto/dh.c
> @@ -71,25 +71,41 @@ static int dh_set_secret(struct crypto_kpp *tfm, const
> void *buf, {
>  	struct dh_ctx *ctx = dh_get_ctx(tfm);
>  	struct dh params;
> +	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
> +	int err;
> 
>  	/* Free the old MPI key if any */
>  	dh_clear_ctx(ctx);
> 
> -	if (crypto_dh_decode_key(buf, len, &params) < 0)
> +	err = crypto_dh_decode_key(buf, len, &params);
> +	if (err)
>  		goto err_clear_ctx;
> 
> -	if (dh_set_params(ctx, &params) < 0)
> +	if (!params.key_size) {

As this params data may come from user space, shouldn't we use the same logic 
as in ecdh's set_key function:

if (!params.key || !params.key_size)

?


> +		err = crypto_dh_gen_privkey(params.group_id, key,
> +					    &params.key_size);
> +		if (err)
> +			goto err_clear_ctx;
> +		params.key = key;
> +	}
> +
> +	err = dh_set_params(ctx, &params);
> +	if (err)
>  		goto err_clear_ctx;
> 
>  	ctx->xa = mpi_read_raw_data(params.key, params.key_size);
> -	if (!ctx->xa)
> +	if (!ctx->xa) {
> +		err = -EINVAL;
>  		goto err_clear_ctx;
> +	}
> +
> +	memzero_explicit(key, sizeof(key));
> 
>  	return 0;
> 
>  err_clear_ctx:
>  	dh_clear_ctx(ctx);
> -	return -EINVAL;
> +	return err;
>  }
> 
>  /*


Ciao
Stephan

Re: [PATCH 10/18] crypto: dh - introduce support for ephemeral key generation to dh-generic

[Nicolai Stange]

Stephan Müller <smueller@chronox.de> writes:

> Am Mittwoch, 1. Dezember 2021, 01:48:50 CET schrieb Nicolai Stange:
>
> Hi Nicolai,
>
>> The support for NVME in-band authentication currently in the works ([1])
>> needs to generate ephemeral DH keys. Make dh-generic's ->set_secret()
>> to generate an ephemeral key via the recently added crypto_dh_gen_privkey()
>> in case the input ->key_size is zero. Note that this behaviour is in
>> analogy to ecdh's ->set_secret().
>> 
>> [1] https://lkml.kernel.org/r/20211122074727.25988-4-hare@suse.de
>> 
>> Signed-off-by: Nicolai Stange <nstange@suse.de>
>> ---
>>  crypto/dh.c | 24 ++++++++++++++++++++----
>>  1 file changed, 20 insertions(+), 4 deletions(-)
>> 
>> diff --git a/crypto/dh.c b/crypto/dh.c
>> index 131b80064cb1..2e49b114e038 100644
>> --- a/crypto/dh.c
>> +++ b/crypto/dh.c
>> @@ -71,25 +71,41 @@ static int dh_set_secret(struct crypto_kpp *tfm, const
>> void *buf, {
>>  	struct dh_ctx *ctx = dh_get_ctx(tfm);
>>  	struct dh params;
>> +	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
>> +	int err;
>> 
>>  	/* Free the old MPI key if any */
>>  	dh_clear_ctx(ctx);
>> 
>> -	if (crypto_dh_decode_key(buf, len, &params) < 0)
>> +	err = crypto_dh_decode_key(buf, len, &params);
>> +	if (err)
>>  		goto err_clear_ctx;
>> 
>> -	if (dh_set_params(ctx, &params) < 0)
>> +	if (!params.key_size) {
>
> As this params data may come from user space, shouldn't we use the same logic 
> as in ecdh's set_key function:
>
> if (!params.key || !params.key_size)

crypto_dh_decode_key() always leaves params.key set even for
!params.key_size, so checking for !params.key wouldn't buy anything
here. FWIW, it seems like it's actually the same for
crypto_ecdh_decode_key().

I'd personally prefer to not add the !params.key check, because it would
suggest that there are code paths which can lead to the condition
params.key_size && !params.key. I would find this confusing when reading
the code, but OTOH I don't have strong objections, so if you insist on
adding the !params.key check, I'd be Ok with it.

Thanks,

Nicolai

>
> ?
>
>
>> +		err = crypto_dh_gen_privkey(params.group_id, key,
>> +					    &params.key_size);
>> +		if (err)
>> +			goto err_clear_ctx;
>> +		params.key = key;
>> +	}
>> +
>> +	err = dh_set_params(ctx, &params);
>> +	if (err)
>>  		goto err_clear_ctx;
>> 
>>  	ctx->xa = mpi_read_raw_data(params.key, params.key_size);
>> -	if (!ctx->xa)
>> +	if (!ctx->xa) {
>> +		err = -EINVAL;
>>  		goto err_clear_ctx;
>> +	}
>> +
>> +	memzero_explicit(key, sizeof(key));
>> 
>>  	return 0;
>> 
>>  err_clear_ctx:
>>  	dh_clear_ctx(ctx);
>> -	return -EINVAL;
>> +	return err;
>>  }
>> 
>>  /*
>
>
> Ciao
> Stephan
>
>

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

[PATCH 11/18] crypto: dh - introduce support for ephemeral key generation to hpre driver

[Nicolai Stange]

A previous patch made the dh-generic implementation's ->set_secret() to
generate an ephemeral key in case the input ->key_size is zero, just in
analogy with ecdh. Make the hpre crypto driver's DH implementation to
behave consistently by doing the same.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a032c192ef1d..02ca79e263f1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -701,11 +701,20 @@ static int hpre_dh_set_secret(struct crypto_kpp *tfm, const void *buf,
 {
 	struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
 	struct dh params;
+	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
 	int ret;
 
 	if (crypto_dh_decode_key(buf, len, &params) < 0)
 		return -EINVAL;
 
+	if (!params.key_size) {
+		ret = crypto_dh_gen_privkey(params.group_id, key,
+					    &params.key_size);
+		if (ret)
+			return ret;
+		params.key = key;
+	}
+
 	/* Free old secret if any */
 	hpre_dh_clear_ctx(ctx, false);
 
@@ -716,6 +725,8 @@ static int hpre_dh_set_secret(struct crypto_kpp *tfm, const void *buf,
 	memcpy(ctx->dh.xa_p + (ctx->key_sz - params.key_size), params.key,
 	       params.key_size);
 
+	memzero_explicit(key, sizeof(key));
+
 	return 0;
 
 err_clear_ctx:
-- 
2.26.2

Re: [PATCH 11/18] crypto: dh - introduce support for ephemeral key generation to hpre driver

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A previous patch made the dh-generic implementation's ->set_secret() to
> generate an ephemeral key in case the input ->key_size is zero, just in
> analogy with ecdh. Make the hpre crypto driver's DH implementation to
> behave consistently by doing the same.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   drivers/crypto/hisilicon/hpre/hpre_crypto.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
Can't really comment here, but FWIW:

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 11/18] crypto: dh - introduce support for ephemeral key generation to hpre driver

[Stephan Müller]

Am Mittwoch, 1. Dezember 2021, 01:48:51 CET schrieb Nicolai Stange:

Hi Nicolai,

> A previous patch made the dh-generic implementation's ->set_secret() to
> generate an ephemeral key in case the input ->key_size is zero, just in
> analogy with ecdh. Make the hpre crypto driver's DH implementation to
> behave consistently by doing the same.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>  drivers/crypto/hisilicon/hpre/hpre_crypto.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> b/drivers/crypto/hisilicon/hpre/hpre_crypto.c index
> a032c192ef1d..02ca79e263f1 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> @@ -701,11 +701,20 @@ static int hpre_dh_set_secret(struct crypto_kpp *tfm,
> const void *buf, {
>  	struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
>  	struct dh params;
> +	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
>  	int ret;
> 
>  	if (crypto_dh_decode_key(buf, len, &params) < 0)
>  		return -EINVAL;
> 
> +	if (!params.key_size) {

dto.

> +		ret = crypto_dh_gen_privkey(params.group_id, key,
> +					    &params.key_size);
> +		if (ret)
> +			return ret;
> +		params.key = key;
> +	}
> +
>  	/* Free old secret if any */
>  	hpre_dh_clear_ctx(ctx, false);
> 
> @@ -716,6 +725,8 @@ static int hpre_dh_set_secret(struct crypto_kpp *tfm,
> const void *buf, memcpy(ctx->dh.xa_p + (ctx->key_sz - params.key_size),
> params.key, params.key_size);
> 
> +	memzero_explicit(key, sizeof(key));
> +
>  	return 0;
> 
>  err_clear_ctx:


Ciao
Stephan

[PATCH 12/18] crypto: dh - introduce support for ephemeral key generation to qat driver

[Nicolai Stange]

A previous patch made the dh-generic implementation's ->set_secret() to
generate an ephemeral key in case the input ->key_size is zero, just in
analogy with ecdh. Make the qat crypto driver's DH implementation to
behave consistently by doing the same.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 drivers/crypto/qat/qat_common/qat_asym_algs.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c b/drivers/crypto/qat/qat_common/qat_asym_algs.c
index b0b78445418b..e0d3a70fa6b1 100644
--- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
@@ -441,11 +441,20 @@ static int qat_dh_set_secret(struct crypto_kpp *tfm, const void *buf,
 	struct qat_dh_ctx *ctx = kpp_tfm_ctx(tfm);
 	struct device *dev = &GET_DEV(ctx->inst->accel_dev);
 	struct dh params;
+	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
 	int ret;
 
 	if (crypto_dh_decode_key(buf, len, &params) < 0)
 		return -EINVAL;
 
+	if (!params.key_size) {
+		ret = crypto_dh_gen_privkey(params.group_id, key,
+					    &params.key_size);
+		if (ret)
+			return ret;
+		params.key = key;
+	}
+
 	/* Free old secret if any */
 	qat_dh_clear_ctx(dev, ctx);
 
-- 
2.26.2

Re: [PATCH 12/18] crypto: dh - introduce support for ephemeral key generation to qat driver

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A previous patch made the dh-generic implementation's ->set_secret() to
> generate an ephemeral key in case the input ->key_size is zero, just in
> analogy with ecdh. Make the qat crypto driver's DH implementation to
> behave consistently by doing the same.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   drivers/crypto/qat/qat_common/qat_asym_algs.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
Similar here.

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 12/18] crypto: dh - introduce support for ephemeral key generation to qat driver

[Stephan Müller]

Am Mittwoch, 1. Dezember 2021, 01:48:52 CET schrieb Nicolai Stange:

Hi Nicolai,

> A previous patch made the dh-generic implementation's ->set_secret() to
> generate an ephemeral key in case the input ->key_size is zero, just in
> analogy with ecdh. Make the qat crypto driver's DH implementation to
> behave consistently by doing the same.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>  drivers/crypto/qat/qat_common/qat_asym_algs.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c
> b/drivers/crypto/qat/qat_common/qat_asym_algs.c index
> b0b78445418b..e0d3a70fa6b1 100644
> --- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
> +++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
> @@ -441,11 +441,20 @@ static int qat_dh_set_secret(struct crypto_kpp *tfm,
> const void *buf, struct qat_dh_ctx *ctx = kpp_tfm_ctx(tfm);
>  	struct device *dev = &GET_DEV(ctx->inst->accel_dev);
>  	struct dh params;
> +	char key[CRYPTO_DH_MAX_PRIVKEY_SIZE];
>  	int ret;
> 
>  	if (crypto_dh_decode_key(buf, len, &params) < 0)
>  		return -EINVAL;
> 
> +	if (!params.key_size) {

dto.

> +		ret = crypto_dh_gen_privkey(params.group_id, key,
> +					    &params.key_size);
> +		if (ret)
> +			return ret;
> +		params.key = key;
> +	}
> +
>  	/* Free old secret if any */
>  	qat_dh_clear_ctx(dev, ctx);


Ciao
Stephan

[PATCH 13/18] crypto: testmgr - add DH test vectors for key generation

[Nicolai Stange]

Now that all DH implementations support ephemeral key generation triggered
by passing a ->key_size of zero to ->set_secret(), it's certainly
worthwhile to build upon the testmgr's do_test_kpp() ->genkey facility to
test it.

Add two ->genkey DH test vectors to the testmgr, one for the RFC 7919
ffdhe2048 group and another one for the RFC 3526 modp2048 group.

All required values have been generated with OpenSSL.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/testmgr.h | 148 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 148 insertions(+)

diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index b295512c8f22..074e5de84a6e 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -1331,6 +1331,80 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
 	},
+	{
+	.secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x00" /* len */
+	"\x01\x00\x00\x00" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x00\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00", /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x00\x14" /* len */
+	"\x00\x00\x00\x01" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x00\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00", /* g_size */
+#endif
+	.b_secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x01" /* len */
+	"\x01\x00\x00\x00" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x01\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x01\x14" /* len */
+	"\x00\x00\x00\x01" /* group_id == dh_group_id_rfc7919_ffdhe2048 */
+	"\x00\x00\x01\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#endif
+	/* xa */
+	"\x1c\x47\xb9\xb9\xe7\x67\x05\x0a\x67\xee\xd2\x4e\xb2\x91\x60\xff"
+	"\xe4\x3e\xe0\x32\xf0\x74\x2b\xaa\x97\x90\xdb\x2d\x1c\x82\x0b\xa9"
+	"\x2b\x9b\x2a\x6a\xe6\xb3\xf5\xa7\xd0\x86\x4f\x0f\xca\x7f\x1c\xfc"
+	"\x36\xf3\x77\xe2\xca\x6e\x20\x3f\x80\x9c\x37\x08\x57\x11\x2d\xbd"
+	"\xb3\x86\xd6\x5f\xa4\xd6\x03\xab\x99\x47\x9f\xe4\x06\x80\xad\x5a"
+	"\x88\x5e\x48\x1d\xd3\x15\x73\xc3\xa3\x2c\xa6\x87\xc3\x53\xca\x65"
+	"\x60\xf8\xcf\xcc\xf1\x17\xa8\x7e\xd4\x71\x77\x7a\x04\x1c\x69\x86"
+	"\x7c\xc9\x7a\x49\xe0\x0c\x5c\x36\xdf\x99\x6c\xd4\xed\xae\x51\x6c"
+	"\xb7\x1d\x29\xb2\xb8\x61\xd1\x4a\x6e\x01\x3c\xc1\xae\x05\x75\xf0"
+	"\xf6\x34\xb2\x09\x18\x38\x3d\xf5\x86\x32\x3d\xf9\xe9\xb2\x80\xc1"
+	"\x95\xb6\x28\xfd\xb6\xc5\xdb\x7a\xf5\x0a\x2c\xc9\x48\xb1\xba\x56"
+	"\x24\x1c\xfc\x6b\x44\x33\x64\x21\x06\x10\x28\x24\xe7\xe8\xa6\xf2"
+	"\x27\xe6\x2a\x7b\xd1\x69\xa4\x2f\x89\xa6\xc9\xce\x3c\x32\x4a\x2d"
+	"\x57\x22\x1b\xbc\x98\x66\x3a\x05\xad\x39\x5a\xb5\x94\xbc\xd8\x8d"
+	"\xe4\x0f\xbc\x39\xe7\xba\xf7\x1b\x0c\x7c\x2d\xae\x7b\x67\xa3\x48"
+	"\xfe\xe7\xef\x98\x15\x52\xe9\xb1\x7c\x1c\x6a\x7e\x3c\x87\xd5\xe7",
+	.b_public =
+	"\x5c\x00\x6f\xda\xfe\x4c\x0c\xc2\x18\xff\xa9\xec\x7a\xbe\x8a\x51"
+	"\x64\x6b\x57\xf8\xed\xe2\x36\x77\xc1\x23\xbf\x56\xa6\x48\x76\x34"
+	"\x0e\xf3\x68\x05\x45\x6a\x98\x5b\x9e\x8b\xc0\x11\x29\xcb\x5b\x66"
+	"\x2d\xc2\xeb\x4c\xf1\x7d\x85\x30\xaa\xd5\xf5\xb8\xd3\x62\x1e\x97"
+	"\x1e\x34\x18\xf8\x76\x8c\x10\xca\x1f\xe4\x5d\x62\xe1\xbe\x61\xef"
+	"\xaf\x2c\x8d\x97\x15\xa5\x86\xd5\xd3\x12\x6f\xec\xe2\xa4\xb2\x5a"
+	"\x35\x1d\xd4\x91\xa6\xef\x13\x09\x65\x9c\x45\xc0\x12\xad\x7f\xee"
+	"\x93\x5d\xfa\x89\x26\x7d\xae\xee\xea\x8c\xa3\xcf\x04\x2d\xa0\xc7"
+	"\xd9\x14\x62\xaf\xdf\xa0\x33\xd7\x5e\x83\xa2\xe6\x0e\x0e\x5d\x77"
+	"\xce\xe6\x72\xe4\xec\x9d\xff\x72\x9f\x38\x95\x19\x96\xba\x4c\xe3"
+	"\x5f\xb8\x46\x4a\x1d\xe9\x62\x7b\xa8\xdc\xe7\x61\x90\x6b\xb9\xd4"
+	"\xad\x0b\xa3\x06\xb3\x70\xfa\xea\x2b\xc4\x2c\xde\x43\x37\xf6\x8d"
+	"\x72\xf0\x86\x9a\xbb\x3b\x8e\x7a\x71\x03\x30\x30\x2a\x5d\xcd\x1e"
+	"\xe4\xd3\x08\x07\x75\x17\x17\x72\x1e\x77\x6c\x98\x0d\x29\x7f\xac"
+	"\xe7\xb2\xee\xa9\x1c\x33\x9d\x08\x39\xe1\xd8\x5b\xe5\xbc\x48\xb2"
+	"\xb6\xdf\xcd\xa0\x42\x06\xcc\xfb\xed\x60\x6f\xbc\x57\xac\x09\x45",
+	.secret_size = 20,
+	.b_secret_size = 276,
+	.b_public_size = 256,
+	.expected_a_public_size = 256,
+	.expected_ss_size = 256,
+	.genkey = true,
+	},
 #elif IS_ENABLED(CONFIG_CRYPTO_DH_GROUPS_RFC3526)
 	{
 	.secret =
@@ -1422,6 +1496,80 @@ static const struct kpp_testvec dh_tv_template[] = {
 	.expected_a_public_size = 256,
 	.expected_ss_size = 256,
 	},
+	{
+	.secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x00" /* len */
+	"\x06\x00\x00\x00" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x00\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00", /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x00\x14" /* len */
+	"\x00\x00\x00\x06" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x00\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00", /* g_size */
+#endif
+	.b_secret =
+#ifdef __LITTLE_ENDIAN
+	"\x01\x00" /* type */
+	"\x14\x01" /* len */
+	"\x06\x00\x00\x00" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x01\x00\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#else
+	"\x00\x01" /* type */
+	"\x01\x14" /* len */
+	"\x00\x00\x00\x06" /* group_id == dh_group_id_rfc3526_modp2048 */
+	"\x00\x00\x01\x00" /* key_size */
+	"\x00\x00\x00\x00" /* p_size */
+	"\x00\x00\x00\x00" /* g_size */
+#endif
+	/* xa */
+	"\x52\xef\x50\xb5\x79\xa6\x02\xbb\x19\x43\x9d\x67\xcc\xc9\x8e\x02"
+	"\x30\x13\xe0\x29\x38\x64\x2e\x57\x10\xbe\xcb\x79\x19\xf2\x45\xc5"
+	"\xd8\x31\x91\x11\x93\x81\xd6\xfa\x11\x03\xc7\xf4\x21\xe6\x6c\x7a"
+	"\xa8\x16\x0c\x13\xda\x14\x69\x52\xaa\xd7\x2a\xee\xa5\xa8\x51\x12"
+	"\x6c\x75\x84\x01\x96\xd7\x57\xec\xb6\x7c\x33\xb2\xd4\xb9\x42\x95"
+	"\xdd\x32\x9a\x09\xfd\x96\x12\x38\xe6\x97\x20\xfa\xba\x10\x5c\x9d"
+	"\xb3\x26\xfb\x93\x33\xc6\x5d\xc2\x1f\x73\x1b\x60\x01\xc6\xc9\x31"
+	"\xc1\x97\xec\x72\x68\x07\xb3\x80\x3a\xbb\xe8\xdd\x58\x32\x53\x06"
+	"\x08\xba\xc0\x0e\x8d\xfc\x54\xb8\x50\x30\xc0\x8b\xfe\xdc\xaa\xe9"
+	"\xe2\x0e\x22\x7b\x4b\x8a\xcc\x2b\xdb\xf2\x47\x1e\x62\xc7\xc1\xba"
+	"\x32\x2e\xec\xb2\xf6\xfa\xa5\xce\x45\xe2\x9e\x9a\xde\x7c\x4a\x6b"
+	"\x75\x45\x91\xe3\x6e\x33\xa5\xa7\x1d\x3a\xd2\x60\x65\xad\x58\xeb"
+	"\x9b\x90\x72\x3b\x0f\xfd\xef\x42\xfd\x1e\x16\x2b\xa1\x8c\xa5\xd9"
+	"\x85\xf6\x2c\xab\x5a\x0c\x68\x64\x6a\xce\xc1\x15\x88\x32\x47\x41"
+	"\x51\x0f\x8e\x37\x72\xf8\x7a\x13\x41\x54\xa9\x02\x1b\x8e\x0d\xb2"
+	"\x7c\xee\xf8\x60\x7e\xb1\x86\xed\x7d\xa1\xca\xf1\xd4\xbc\x81\xd8",
+	.b_public =
+	"\x75\x98\x23\x19\xc9\xc2\xe1\x59\x73\xc2\x1d\xc5\x2c\xad\x22\x90"
+	"\xa8\xa4\xb4\xfa\xd7\x67\x5b\xe9\xa1\x0e\x15\x3b\x5d\xae\xd3\x25"
+	"\x29\xfc\x26\x79\xd6\x86\xf2\x21\x20\x86\xd7\x17\xce\xe7\x6a\x74"
+	"\x3e\x2e\x8b\x62\x87\x62\xe9\x27\xc0\x57\xca\x5b\xaf\x86\x22\xd6"
+	"\xdd\xf6\x88\xd2\x86\x21\xf7\x39\x6a\x3f\x52\x17\x03\xdc\xb9\x44"
+	"\x03\xdf\xb5\x6e\x5d\x15\x50\x6f\xf8\x9a\x3c\xee\x9f\xc5\x01\x23"
+	"\xd8\x2d\xb8\x18\x37\xc8\xed\x7d\x46\x27\x03\xc9\xae\x3b\xbf\x9e"
+	"\x4e\x98\x91\x30\x56\xcb\x09\x6b\x8e\xd3\xe5\x87\xfe\x82\x66\x36"
+	"\x2c\xee\x88\x74\x00\x8a\x2d\x36\x39\x2b\xe7\xbd\x18\x21\x36\xd0"
+	"\x98\x34\x6c\xb1\x4f\xbf\xd0\x0c\xd3\x6c\x64\x2e\x04\xfa\x68\x13"
+	"\x51\xaf\x1b\xc8\xc3\xbd\x13\x44\x72\x89\xd5\xa3\xd8\x83\x22\xf1"
+	"\x92\xeb\x5a\x70\x5e\x91\x1e\x86\xb9\x2f\x18\x44\x8c\x5a\xe0\x18"
+	"\x6c\x7a\xc6\x20\x27\x27\xae\x6a\x9e\x1b\x9b\xae\x13\xc9\x73\x22"
+	"\x0c\x0d\xdf\x97\x9c\x87\x06\x48\xdc\xe0\x8d\x83\xe1\x32\x8a\x8f"
+	"\x80\x60\x70\x7c\x7e\x10\x10\xf0\xd7\x49\x09\xfc\xf0\x0e\x11\x3f"
+	"\xb4\x5a\x9e\x3d\x38\x28\x3d\x46\x5a\x63\x6c\x9e\x14\xe3\x7c\x13",
+	.secret_size = 20,
+	.b_secret_size = 276,
+	.b_public_size = 256,
+	.expected_a_public_size = 256,
+	.expected_ss_size = 256,
+	.genkey = true,
+	},
 #else
 	{
 	.secret =
-- 
2.26.2

Re: [PATCH 13/18] crypto: testmgr - add DH test vectors for key generation

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> Now that all DH implementations support ephemeral key generation triggered
> by passing a ->key_size of zero to ->set_secret(), it's certainly
> worthwhile to build upon the testmgr's do_test_kpp() ->genkey facility to
> test it.
> 
> Add two ->genkey DH test vectors to the testmgr, one for the RFC 7919
> ffdhe2048 group and another one for the RFC 3526 modp2048 group.
> 
As noted previously, maybe you can consider switching to ffdhe3072 here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 14/18] lib/mpi: export mpi_rshift

[Nicolai Stange]

A subsequent patch will make the crypto/dh's dh_is_pubkey_valid() to
calculate a safe-prime groups Q parameter from P: Q = (P - 1) / 2. For
implementing this, mpi_rshift() will be needed. Export it so that it's
accessible from crypto/dh.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 lib/mpi/mpi-bit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/mpi/mpi-bit.c b/lib/mpi/mpi-bit.c
index 142b680835df..070ba784c9f1 100644
--- a/lib/mpi/mpi-bit.c
+++ b/lib/mpi/mpi-bit.c
@@ -242,6 +242,7 @@ void mpi_rshift(MPI x, MPI a, unsigned int n)
 	}
 	MPN_NORMALIZE(x->d, x->nlimbs);
 }
+EXPORT_SYMBOL_GPL(mpi_rshift);
 
 /****************
  * Shift A by COUNT limbs to the left
-- 
2.26.2

Re: [PATCH 14/18] lib/mpi: export mpi_rshift

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A subsequent patch will make the crypto/dh's dh_is_pubkey_valid() to
> calculate a safe-prime groups Q parameter from P: Q = (P - 1) / 2. For
> implementing this, mpi_rshift() will be needed. Export it so that it's
> accessible from crypto/dh.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   lib/mpi/mpi-bit.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/lib/mpi/mpi-bit.c b/lib/mpi/mpi-bit.c
> index 142b680835df..070ba784c9f1 100644
> --- a/lib/mpi/mpi-bit.c
> +++ b/lib/mpi/mpi-bit.c
> @@ -242,6 +242,7 @@ void mpi_rshift(MPI x, MPI a, unsigned int n)
>   	}
>   	MPN_NORMALIZE(x->d, x->nlimbs);
>   }
> +EXPORT_SYMBOL_GPL(mpi_rshift);
>   
>   /****************
>    * Shift A by COUNT limbs to the left
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 15/18] crypto: dh - store group id in dh-generic's dh_ctx

[Nicolai Stange]

A subsequent patch will make the crypto/dh's dh_is_pubkey_valid() to
calculate the Q value from the P domain parameter for safe-prime groups,
for which by definition Q = (P - 1)/2. However, dh_is_pubkey_valid() will
need to check first whether the group in question is actually a safe-prime
group. In order to make this information available, introduce a new
->group_id member to struct dh_ctx and let dh_set_params() set it to the
value found in the struct dh as deserialized via crypto_dh_decode_key().

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/crypto/dh.c b/crypto/dh.c
index 2e49b114e038..38547c5301da 100644
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -13,6 +13,7 @@
 #include <linux/mpi.h>
 
 struct dh_ctx {
+	enum dh_group_id group_id;
 	MPI p;	/* Value is guaranteed to be set. */
 	MPI q;	/* Value is optional. */
 	MPI g;	/* Value is guaranteed to be set. */
@@ -55,6 +56,8 @@ static int dh_set_params(struct dh_ctx *ctx, struct dh *params)
 	if (dh_check_params_length(params->p_size << 3))
 		return -EINVAL;
 
+	ctx->group_id = params->group_id;
+
 	ctx->p = mpi_read_raw_data(params->p, params->p_size);
 	if (!ctx->p)
 		return -EINVAL;
-- 
2.26.2

Re: [PATCH 15/18] crypto: dh - store group id in dh-generic's dh_ctx

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A subsequent patch will make the crypto/dh's dh_is_pubkey_valid() to
> calculate the Q value from the P domain parameter for safe-prime groups,
> for which by definition Q = (P - 1)/2. However, dh_is_pubkey_valid() will
> need to check first whether the group in question is actually a safe-prime
> group. In order to make this information available, introduce a new
> ->group_id member to struct dh_ctx and let dh_set_params() set it to the
> value found in the struct dh as deserialized via crypto_dh_decode_key().
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

[Nicolai Stange]

As the ->q in struct dh_ctx gets never set anywhere, the code
in dh_is_pubkey_valid() for doing the full public key validation in
accordance to SP800-56Arev3 is effectively dead.

However, for safe-prime groups, Q = (P - 1)/2 by definition and this
enables dh_is_pubkey_valid() to calculate Q on the fly for these groups.
Implement this.

With this change, the last code accessing struct dh_ctx's ->q is now gone.
Remove this member from struct dh_ctx.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh.c | 40 +++++++++++++++++++++++++++++-----------
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/crypto/dh.c b/crypto/dh.c
index 38547c5301da..21de91a87ea5 100644
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -15,7 +15,6 @@
 struct dh_ctx {
 	enum dh_group_id group_id;
 	MPI p;	/* Value is guaranteed to be set. */
-	MPI q;	/* Value is optional. */
 	MPI g;	/* Value is guaranteed to be set. */
 	MPI xa;	/* Value is guaranteed to be set. */
 };
@@ -23,7 +22,6 @@ struct dh_ctx {
 static void dh_clear_ctx(struct dh_ctx *ctx)
 {
 	mpi_free(ctx->p);
-	mpi_free(ctx->q);
 	mpi_free(ctx->g);
 	mpi_free(ctx->xa);
 	memset(ctx, 0, sizeof(*ctx));
@@ -114,11 +112,12 @@ static int dh_set_secret(struct crypto_kpp *tfm, const void *buf,
 /*
  * SP800-56A public key verification:
  *
- * * If Q is provided as part of the domain paramenters, a full validation
- *   according to SP800-56A section 5.6.2.3.1 is performed.
+ * * For safe-prime groups, Q can be computed trivially from P and a
+ *   full validation according to SP800-56A section 5.6.2.3.1 is
+ *   performed.
  *
- * * If Q is not provided, a partial validation according to SP800-56A section
- *   5.6.2.3.2 is performed.
+ * * For all other sets of group parameters, only a partial validation
+ *   according to SP800-56A section 5.6.2.3.2 is performed.
  */
 static int dh_is_pubkey_valid(struct dh_ctx *ctx, MPI y)
 {
@@ -129,21 +128,40 @@ static int dh_is_pubkey_valid(struct dh_ctx *ctx, MPI y)
 	 * Step 1: Verify that 2 <= y <= p - 2.
 	 *
 	 * The upper limit check is actually y < p instead of y < p - 1
-	 * as the mpi_sub_ui function is yet missing.
+	 * in order to save one mpi_sub_ui() invocation here. Note that
+	 * p - 1 is the non-trivial element of the subgroup of order 2 and
+	 * thus, the check on y^q below would fail if y == p - 1.
 	 */
 	if (mpi_cmp_ui(y, 1) < 1 || mpi_cmp(y, ctx->p) >= 0)
 		return -EINVAL;
 
-	/* Step 2: Verify that 1 = y^q mod p */
-	if (ctx->q) {
-		MPI val = mpi_alloc(0);
+	/*
+	 * Step 2: Verify that 1 = y^q mod p
+	 *
+	 * For the safe-prime groups q = (p - 1)/2.
+	 */
+	if (ctx->group_id != dh_group_id_unknown) {
+		MPI val, q;
 		int ret;
 
+		val = mpi_alloc(0);
 		if (!val)
 			return -ENOMEM;
 
-		ret = mpi_powm(val, y, ctx->q, ctx->p);
+		q = mpi_alloc(mpi_get_nlimbs(ctx->p));
+		if (!q) {
+			mpi_free(val);
+			return -ENOMEM;
+		}
+
+		/*
+		 * ->p is odd, so no need to explicitly subtract one
+		 * from it before shifting to the right.
+		 */
+		mpi_rshift(q, ctx->p, 1);
 
+		ret = mpi_powm(val, y, q, ctx->p);
+		mpi_free(q);
 		if (ret) {
 			mpi_free(val);
 			return ret;
-- 
2.26.2

Re: [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> As the ->q in struct dh_ctx gets never set anywhere, the code
> in dh_is_pubkey_valid() for doing the full public key validation in
> accordance to SP800-56Arev3 is effectively dead.
> 
> However, for safe-prime groups, Q = (P - 1)/2 by definition and this
> enables dh_is_pubkey_valid() to calculate Q on the fly for these groups.
> Implement this.
> 
> With this change, the last code accessing struct dh_ctx's ->q is now gone.
> Remove this member from struct dh_ctx.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh.c | 40 +++++++++++++++++++++++++++++-----------
>   1 file changed, 29 insertions(+), 11 deletions(-)
> Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

[Stephan Müller]

Am Mittwoch, 1. Dezember 2021, 01:48:56 CET schrieb Nicolai Stange:

Hi Nicolai,

> As the ->q in struct dh_ctx gets never set anywhere, the code
> in dh_is_pubkey_valid() for doing the full public key validation in
> accordance to SP800-56Arev3 is effectively dead.
> 
> However, for safe-prime groups, Q = (P - 1)/2 by definition and this
> enables dh_is_pubkey_valid() to calculate Q on the fly for these groups.
> Implement this.
> 
> With this change, the last code accessing struct dh_ctx's ->q is now gone.
> Remove this member from struct dh_ctx.

Isn't it expensive to always calculate Q for a-priori known values? Why not 
add Q to the safe-prime definitions and do not do this operation here?

If you need Q for all of those safe-primes, you may get them from [1] and 
following lines.

[1] https://github.com/smuellerDD/acvpparser/blob/master/parser/
safeprimes.h#L346

Ciao
Stephan

Re: [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

[Nicolai Stange]

Stephan Müller <smueller@chronox.de> writes:

> Am Mittwoch, 1. Dezember 2021, 01:48:56 CET schrieb Nicolai Stange:
>
>> As the ->q in struct dh_ctx gets never set anywhere, the code
>> in dh_is_pubkey_valid() for doing the full public key validation in
>> accordance to SP800-56Arev3 is effectively dead.
>> 
>> However, for safe-prime groups, Q = (P - 1)/2 by definition and this
>> enables dh_is_pubkey_valid() to calculate Q on the fly for these groups.
>> Implement this.
>> 
>> With this change, the last code accessing struct dh_ctx's ->q is now gone.
>> Remove this member from struct dh_ctx.
>
> Isn't it expensive to always calculate Q for a-priori known values? Why not 
> add Q to the safe-prime definitions and do not do this operation here?

I actually considered this when writing the patch: it's basically a
time-memory tradeoff and I opted for time here. The reason is that I'd
expect the rather trivial Q calculation to be negligible when compared
to the subsequent mpi_powm() operation in dh_is_pubkey_valid(). OTOH, as
the size of Q is (almost) equal to that of P, the space needed for
storing all the the individual groups' precomputed Qs would be
significant. So I'd say let's wait and see whether the dynamic Q
calculation does actually show up in profiles before thinking about
optimizations like e.g. precomputations.

Thanks,

Nicolai

>
> If you need Q for all of those safe-primes, you may get them from [1] and 
> following lines.
>
> [1] https://github.com/smuellerDD/acvpparser/blob/master/parser/
> safeprimes.h#L346
>
> Ciao
> Stephan
>
>

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev

[PATCH 17/18] crypto: dh - try to match domain parameters to a known safe-prime group

[Nicolai Stange]

A subsequent patch will make the DH implementation to reject any input
domain parameter set with ->group_id == dh_group_id_unknown in FIPS mode.
However, as the keyctl(KEYCTL_DH_COMPUTE) implementation simply passes
forward keys from userspace, it does not (and cannot) set ->group_id to
anything else than dh_group_id_unknown.

In order to still allow for keyctl(KEYCTL_DH_COMPUTE) to work on approved
domain parameters passed in from userspace in FIPS mode, make
crypto_dh_decode_key() to compare them against any of the known groups and
set ->group_id upon having found a match, if any.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/dh_helper.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index 5a8c9c50297f..cf632beca65e 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -471,6 +471,36 @@ get_safe_prime_group(enum dh_group_id group_id)
 	return NULL;
 }
 
+static enum dh_group_id lookup_group_id(const char *g, size_t g_size,
+					const char *p, size_t p_size)
+{
+	int i;
+
+	/* All safe-prime groups use a generator of g == 2. */
+	while (g_size && !*g) {
+		++g;
+		--g_size;
+	}
+
+	if (g_size != 1 || *g != 2)
+		return dh_group_id_unknown;
+
+	while (p_size && !*p) {
+		++p;
+		--p_size;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(safe_prime_groups); ++i) {
+		if (safe_prime_groups[i].p_size != p_size)
+			continue;
+
+		if (!memcmp(safe_prime_groups[i].p, p, p_size))
+			return safe_prime_groups[i].group_id;
+	}
+
+	return dh_group_id_unknown;
+}
+
 static inline u8 *dh_pack_data(u8 *dst, u8 *end, const void *src, size_t size)
 {
 	if (!dst || size > end - dst)
@@ -566,6 +596,9 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 		if (memchr_inv(params->p, 0, params->p_size) == NULL)
 			return -EINVAL;
 
+		params->group_id = lookup_group_id(params->g, params->g_size,
+						   params->p, params->p_size);
+
 	} else {
 		const struct safe_prime_group *g;
 
-- 
2.26.2

Re: [PATCH 17/18] crypto: dh - try to match domain parameters to a known safe-prime group

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> A subsequent patch will make the DH implementation to reject any input
> domain parameter set with ->group_id == dh_group_id_unknown in FIPS mode.
> However, as the keyctl(KEYCTL_DH_COMPUTE) implementation simply passes
> forward keys from userspace, it does not (and cannot) set ->group_id to
> anything else than dh_group_id_unknown.
> 
> In order to still allow for keyctl(KEYCTL_DH_COMPUTE) to work on approved
> domain parameters passed in from userspace in FIPS mode, make
> crypto_dh_decode_key() to compare them against any of the known groups and
> set ->group_id upon having found a match, if any.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/dh_helper.c | 33 +++++++++++++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

[PATCH 18/18] crypto: dh - accept only approved safe-prime groups in FIPS mode

[Nicolai Stange]

SP800-56Arev3, sec. 5.5.2 ("Assurance of Domain-Parameter Validity")
asserts that an implementation needs to verify domain paramtere validity,
which boils down to either
- the domain parameters corresponding to some known safe-prime group
  explicitly listed to be approved in the document or
- for parameters conforming to a "FIPS 186-type parameter-size set",
  that the implementation needs to perform an explicit domain parameter
  verification, which would require access to the "seed" and "counter"
  values used in their generation.

The latter is not easily feasible and moreover, SP800-56Arev3 states that
safe-prime groups are preferred and that FIPS 186-type parameter sets
should only be supported for backward compatibility, if it all.

Make the dh implementations reject any domain parameters which don't
correspond to any of the approved safe-prime groups in FIPS mode. The
approved safe-prime groups are the ones specified in RFC 7919 and RFC 3526,
and given that all possible values of enum dh_group_id correspond to
either groups from these RFCs or to dh_group_id_unknown, it suffices to
make crypto_dh_decode_key() to reject any parameter set where
->group_id == dh_group_id_unknown.

As this change will effectively render the dh implementation unusable in
FIPS mode if neither of the CRYPTO_DH_GROUPS_RFC7919 or
CRYPTO_DH_GROUPS_RFC3526 Kconfig options enabled, make CRYPTO_DH imply
these two if CRYPTO_FIPS is set.

Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 crypto/Kconfig     | 2 ++
 crypto/dh_helper.c | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 578711b02bb3..571f2271ad2e 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -229,6 +229,8 @@ menuconfig CRYPTO_DH
 	select CRYPTO_KPP
 	select MPILIB
 	select CRYPTO_RNG_DEFAULT
+	imply CRYPTO_DH_GROUPS_RFC7919 if CRYPTO_FIPS
+	imply CRYPTO_DH_GROUPS_RFC3526 if CRYPTO_FIPS
 	help
 	  Generic implementation of the Diffie-Hellman algorithm.
 
diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
index cf632beca65e..f30674df0d76 100644
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -7,6 +7,7 @@
 #include <linux/export.h>
 #include <linux/err.h>
 #include <linux/string.h>
+#include <linux/fips.h>
 #include <crypto/dh.h>
 #include <crypto/kpp.h>
 #include <crypto/rng.h>
@@ -622,6 +623,9 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
 	    params->g_size > params->p_size)
 		return -EINVAL;
 
+	/* Only safe-prime groups are allowed in FIPS mode. */
+	if (fips_enabled && params->group_id == dh_group_id_unknown)
+		return -EINVAL;
 
 	return 0;
 }
-- 
2.26.2

Re: [PATCH 18/18] crypto: dh - accept only approved safe-prime groups in FIPS mode

[Hannes Reinecke]

On 12/1/21 1:48 AM, Nicolai Stange wrote:
> SP800-56Arev3, sec. 5.5.2 ("Assurance of Domain-Parameter Validity")
> asserts that an implementation needs to verify domain paramtere validity,
> which boils down to either
> - the domain parameters corresponding to some known safe-prime group
>    explicitly listed to be approved in the document or
> - for parameters conforming to a "FIPS 186-type parameter-size set",
>    that the implementation needs to perform an explicit domain parameter
>    verification, which would require access to the "seed" and "counter"
>    values used in their generation.
> 
> The latter is not easily feasible and moreover, SP800-56Arev3 states that
> safe-prime groups are preferred and that FIPS 186-type parameter sets
> should only be supported for backward compatibility, if it all.
> 
> Make the dh implementations reject any domain parameters which don't
> correspond to any of the approved safe-prime groups in FIPS mode. The
> approved safe-prime groups are the ones specified in RFC 7919 and RFC 3526,
> and given that all possible values of enum dh_group_id correspond to
> either groups from these RFCs or to dh_group_id_unknown, it suffices to
> make crypto_dh_decode_key() to reject any parameter set where
> ->group_id == dh_group_id_unknown.
> 
> As this change will effectively render the dh implementation unusable in
> FIPS mode if neither of the CRYPTO_DH_GROUPS_RFC7919 or
> CRYPTO_DH_GROUPS_RFC3526 Kconfig options enabled, make CRYPTO_DH imply
> these two if CRYPTO_FIPS is set.
> 
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> ---
>   crypto/Kconfig     | 2 ++
>   crypto/dh_helper.c | 4 ++++
>   2 files changed, 6 insertions(+)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 578711b02bb3..571f2271ad2e 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -229,6 +229,8 @@ menuconfig CRYPTO_DH
>   	select CRYPTO_KPP
>   	select MPILIB
>   	select CRYPTO_RNG_DEFAULT
> +	imply CRYPTO_DH_GROUPS_RFC7919 if CRYPTO_FIPS
> +	imply CRYPTO_DH_GROUPS_RFC3526 if CRYPTO_FIPS
>   	help
>   	  Generic implementation of the Diffie-Hellman algorithm.
>   
> diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
> index cf632beca65e..f30674df0d76 100644
> --- a/crypto/dh_helper.c
> +++ b/crypto/dh_helper.c
> @@ -7,6 +7,7 @@
>   #include <linux/export.h>
>   #include <linux/err.h>
>   #include <linux/string.h>
> +#include <linux/fips.h>
>   #include <crypto/dh.h>
>   #include <crypto/kpp.h>
>   #include <crypto/rng.h>
> @@ -622,6 +623,9 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
>   	    params->g_size > params->p_size)
>   		return -EINVAL;
>   
> +	/* Only safe-prime groups are allowed in FIPS mode. */
> +	if (fips_enabled && params->group_id == dh_group_id_unknown)
> +		return -EINVAL;
>   
>   	return 0;
>   }
> 
That was cheap.
Maybe merge it with the previous patch?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.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

Re: [PATCH 18/18] crypto: dh - accept only approved safe-prime groups in FIPS mode

[Nicolai Stange]

Hannes Reinecke <hare@suse.de> writes:

> On 12/1/21 1:48 AM, Nicolai Stange wrote:
>> SP800-56Arev3, sec. 5.5.2 ("Assurance of Domain-Parameter Validity")
>> asserts that an implementation needs to verify domain paramtere validity,
>> which boils down to either
>> - the domain parameters corresponding to some known safe-prime group
>>    explicitly listed to be approved in the document or
>> - for parameters conforming to a "FIPS 186-type parameter-size set",
>>    that the implementation needs to perform an explicit domain parameter
>>    verification, which would require access to the "seed" and "counter"
>>    values used in their generation.
>>
>> The latter is not easily feasible and moreover, SP800-56Arev3 states that
>> safe-prime groups are preferred and that FIPS 186-type parameter sets
>> should only be supported for backward compatibility, if it all.
>>
>> Make the dh implementations reject any domain parameters which don't
>> correspond to any of the approved safe-prime groups in FIPS mode. The
>> approved safe-prime groups are the ones specified in RFC 7919 and RFC 3526,
>> and given that all possible values of enum dh_group_id correspond to
>> either groups from these RFCs or to dh_group_id_unknown, it suffices to
>> make crypto_dh_decode_key() to reject any parameter set where
>> ->group_id == dh_group_id_unknown.
>>
>> As this change will effectively render the dh implementation unusable in
>> FIPS mode if neither of the CRYPTO_DH_GROUPS_RFC7919 or
>> CRYPTO_DH_GROUPS_RFC3526 Kconfig options enabled, make CRYPTO_DH imply
>> these two if CRYPTO_FIPS is set.
>>
>> Signed-off-by: Nicolai Stange <nstange@suse.de>
>> ---
>>   crypto/Kconfig     | 2 ++
>>   crypto/dh_helper.c | 4 ++++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index 578711b02bb3..571f2271ad2e 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -229,6 +229,8 @@ menuconfig CRYPTO_DH
>>   	select CRYPTO_KPP
>>   	select MPILIB
>>   	select CRYPTO_RNG_DEFAULT
>> +	imply CRYPTO_DH_GROUPS_RFC7919 if CRYPTO_FIPS
>> +	imply CRYPTO_DH_GROUPS_RFC3526 if CRYPTO_FIPS
>>   	help
>>   	  Generic implementation of the Diffie-Hellman algorithm.
>>   diff --git a/crypto/dh_helper.c b/crypto/dh_helper.c
>> index cf632beca65e..f30674df0d76 100644
>> --- a/crypto/dh_helper.c
>> +++ b/crypto/dh_helper.c
>> @@ -7,6 +7,7 @@
>>   #include <linux/export.h>
>>   #include <linux/err.h>
>>   #include <linux/string.h>
>> +#include <linux/fips.h>
>>   #include <crypto/dh.h>
>>   #include <crypto/kpp.h>
>>   #include <crypto/rng.h>
>> @@ -622,6 +623,9 @@ int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params)
>>   	    params->g_size > params->p_size)
>>   		return -EINVAL;
>>   +	/* Only safe-prime groups are allowed in FIPS mode. */
>> +	if (fips_enabled && params->group_id == dh_group_id_unknown)
>> +		return -EINVAL;
>>     	return 0;
>>   }
>>
> That was cheap.
> Maybe merge it with the previous patch?

FWIW, I kept this separate in v2: the code change is trivial for sure,
but as this is FIPS related, the premise might be controversial and I
don't want to hide it in a larger patch.

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev