Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Nicolai Stange <nstange@suse.de>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Nicolai Stange <nstange@suse.de>,
        "David S. Miller" <davem@davemloft.net>,
        Stephan =?utf-8?Q?M=C3=BCller?= <smueller@chronox.de>,
        Hannes Reinecke <hare@suse.de>, Torsten Duwe <duwe@suse.de>,
        David Howells <dhowells@redhat.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
        keyrings@vger.kernel.org
Subject: Re: [PATCH v3 11/15] crypto: dh - allow for passing NULL to the ffdheXYZ(dh)s' ->set_secret()
References: <20220202104012.4193-1-nstange@suse.de>
        <20220202104012.4193-12-nstange@suse.de>
        <YgYnu8ZzhSnr+OgZ@gondor.apana.org.au>
Date:   Mon, 14 Feb 2022 09:53:40 +0100
In-Reply-To: <YgYnu8ZzhSnr+OgZ@gondor.apana.org.au> (Herbert Xu's message of
        "Fri, 11 Feb 2022 20:09:15 +1100")
Message-ID: <87bkz9q163.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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 =3D=3D 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.
>>=20
>> 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.
>>=20
>> That is, it is now possible to call
>>=20
>>   crypto_kpp_set_secret(tfm, NULL, 0);
>>=20
>> 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

--=20
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, G=
ermany
(HRB 36809, AG N=C3=BCrnberg), GF: Ivo Totev