| Message ID | 20220202104012.4193-12-nstange@suse.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: dh - infrastructure for NVM in-band auth and FIPS conformance | expand |
On Wed, Feb 02, 2022 at 11:40:08AM +0100, Nicolai Stange wrote: > Ephemeral key generation can be requested from any of the ffdheXYZ(dh) > variants' common ->set_secret() by passing it an (encoded) struct dh > with the key parameter being unset, i.e. with ->key_size == 0. As the > whole purpose of the ffdheXYZ(dh) templates is to fill in the group > parameters as appropriate, they expect ->p and ->g to be unset in any > input struct dh as well. This means that a user would have to encode an > all-zeroes struct dh instance via crypto_dh_encode_key() when requesting > ephemeral key generation from a ffdheXYZ(dh) instance, which is kind of > pointless. > > Make dh_safe_prime_set_secret() to decode a struct dh from the supplied > buffer only if the latter is non-NULL and initialize it with all zeroes > otherwise. > > That is, it is now possible to call > > crypto_kpp_set_secret(tfm, NULL, 0); > > on any ffdheXYZ(dh) tfm for requesting ephemeral key generation. Why do we need to support the non-NULL case? IOW what in the kernel will be using these new templates with a non-NULL parameter? Thanks,
Herbert Xu <herbert@gondor.apana.org.au> writes: > On Wed, Feb 02, 2022 at 11:40:08AM +0100, Nicolai Stange wrote: >> Ephemeral key generation can be requested from any of the ffdheXYZ(dh) >> variants' common ->set_secret() by passing it an (encoded) struct dh >> with the key parameter being unset, i.e. with ->key_size == 0. As the >> whole purpose of the ffdheXYZ(dh) templates is to fill in the group >> parameters as appropriate, they expect ->p and ->g to be unset in any >> input struct dh as well. This means that a user would have to encode an >> all-zeroes struct dh instance via crypto_dh_encode_key() when requesting >> ephemeral key generation from a ffdheXYZ(dh) instance, which is kind of >> pointless. >> >> Make dh_safe_prime_set_secret() to decode a struct dh from the supplied >> buffer only if the latter is non-NULL and initialize it with all zeroes >> otherwise. >> >> That is, it is now possible to call >> >> crypto_kpp_set_secret(tfm, NULL, 0); >> >> on any ffdheXYZ(dh) tfm for requesting ephemeral key generation. > > Why do we need to support the non-NULL case? IOW what in the kernel > will be using these new templates with a non-NULL parameter? The only "real" user, NVME in-band auth, will indeed only use ephemeral keys AFAICT, but the known-answer selftests install a static key each. So those will have to invoke ->set_secret() with a non-NULL parameter. Thanks, Nicolai
diff --git a/crypto/dh.c b/crypto/dh.c index 869a0476e5e2..d0d24f615b2d 100644 --- a/crypto/dh.c +++ b/crypto/dh.c @@ -444,17 +444,18 @@ static int dh_safe_prime_set_secret(struct crypto_kpp *tfm, const void *buffer, struct dh_safe_prime_instance_ctx *inst_ctx = dh_safe_prime_instance_ctx(tfm); struct dh_safe_prime_tfm_ctx *tfm_ctx = kpp_tfm_ctx(tfm); - struct dh params; + struct dh params = {}; void *buf = NULL, *key = NULL; unsigned int buf_size; int err; - err = __crypto_dh_decode_key(buffer, len, ¶ms); - if (err) - return err; - - if (params.p_size || params.g_size) - return -EINVAL; + if (buffer) { + err = __crypto_dh_decode_key(buffer, len, ¶ms); + if (err) + return err; + if (params.p_size || params.g_size) + return -EINVAL; + } params.p = inst_ctx->safe_prime->p; params.p_size = inst_ctx->safe_prime->p_size;
Ephemeral key generation can be requested from any of the ffdheXYZ(dh) variants' common ->set_secret() by passing it an (encoded) struct dh with the key parameter being unset, i.e. with ->key_size == 0. As the whole purpose of the ffdheXYZ(dh) templates is to fill in the group parameters as appropriate, they expect ->p and ->g to be unset in any input struct dh as well. This means that a user would have to encode an all-zeroes struct dh instance via crypto_dh_encode_key() when requesting ephemeral key generation from a ffdheXYZ(dh) instance, which is kind of pointless. Make dh_safe_prime_set_secret() to decode a struct dh from the supplied buffer only if the latter is non-NULL and initialize it with all zeroes otherwise. That is, it is now possible to call crypto_kpp_set_secret(tfm, NULL, 0); on any ffdheXYZ(dh) tfm for requesting ephemeral key generation. Signed-off-by: Nicolai Stange <nstange@suse.de> --- crypto/dh.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)