On Thu, Dec 09, 2021 at 10:03:43AM +0100, Nicolai Stange wrote:
>> diff --git a/include/crypto/dh.h b/include/crypto/dh.h
> index 67f3f6bca527..f0ed899e2168 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, /* Constants are used in test vectors. */
> +};
We try to avoid hard-coded ID lists like these in the Crypto API.
I've had a look at your subsequent patches and I don't think you
really need this.
For instance, instead of shoehorning this into "dh", you could
instead create new kpp algorithms modpXXXX and ffdheXXXX which
can be templates around the underlying dh algorithm. Sure this
might involve a copy of the parameters but given the speed of
the algorithms that we're talking about here I don't think it's
really relevant.
That way the underlying drivers don't need to be touched at all.
Yes I do realise that this means the keyrings DH user-space API
cannot be used in FIPS mode, but that is probably a good thing
as users who care about modp/ffdhe shouldn't really have to stuff
the raw vectors into this interface just to access the kernel DH
implementation.
On a side note, are there really keyrings DH users out there in
the wild? If not can we deprecate and remove this interface
completely?
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
