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

[Stephan Mueller]

Am Mittwoch, 2. Februar 2022, 11:39:57 CET schrieb Nicolai Stange:

Hi Nicolai,

> 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 4/15. It would be
> great to get ACKs for that...
> 
> This is a complete rework of the v2 patchset to be found at [1]. Most
> notably, the ffdheXYZ groups are now made accessible by means of templates
> wrapping the generic dh: ffdhe2048(dh) ffdhe3072(dh), etc, rather than by
> that fixed enum dh_group_id as before. For your reference, this change has
> been suggested at [2].
> 
> Plain "dh" usage will be disallowed in FIPS mode now, which will break
> keyctl(KEYCTL_DH_COMPUTE) functionality in FIPS mode. As per the
> discussion from [2], this is acceptable or perhaps even desirable.
> 
> The only motivation to include the RFC 3526 MODP groups in the previous v2
> had been to keep keyctl(KEYCTL_DH_COMPUTE) somewhat workable in FIPS mode.
> These groups have been dropped accordingly now and this patchset only
> introduces support for the RFC 7919 FFDHE groups, which is what is needed
> by NVM in-band authentication.
> 
> In order to be able to restrict plain "dh" usage in FIPS mode while
> still allowing the usage of those new ffdheXYZ(dh) instantiations, I
> incorporated a modified version of the patch posted by Herbert at
> [3] ("crypto: api - Disallow sha1 in FIPS-mode while allowing hmac(sha1)")
> into this series here as [12/15] ("crypto: api - allow algs only in
> specific constructions in FIPS mode"). There had been two changes worth
> mentioning:
> - An attempt to make it more generic by having crypto_grab_spawn()
>   to include FIPS_INTERNAL in the lookup and also, to let
>   crypto_register_instance() to propagate this flag from the
>   child spawns into the instance to be registered.
> - To skip the actual self-test executions for !->fips_allowed algorithms,
>   just as before. The rationale for this can be found in the discussion to
>   [3].
> With these changes, all breakage is to blame on me and thus, I assumed
> authorship of this patch. I reflected the fact that this is heavily based
> on Herbert's work by means of an Originally-by tag and sincerely hope this
> is an appropriate way of recording the patch's history.
> 
> This series has been tested on x86_64 and s390x (big endian) with FIPS mode
> both enabled and disabled each.

Using the NIST ACVP reference implementation, shared secret computation and 
key generation was successfully tested.

Tested-by: Stephan Mueller <smueller@xxxxxxxxxx>


Ciao
Stephan