Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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 -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Ivo Totev
