Re: [v2 PATCH] crypto: api - Disallow sha1 in FIPS-mode while allowing hmac(sha1)

From: James Bottomley
Date: Fri Jan 14 2022 - 07:54:29 EST


On Fri, 2022-01-14 at 13:35 +0100, Stephan Mueller wrote:
> Am Freitag, 14. Januar 2022, 11:55:26 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
> > > On an unrelated note, this will break trusted_key_tpm_ops->init()
> > > in FIPS mode, because trusted_shash_alloc() would fail to get a
> > > hold of sha1. AFAICT, this could potentially make the
> > > init_trusted() module_init to fail, and, as encrypted-keys.ko
> > > imports key_type_trusted, prevent the loading of that one as
> > > well. Not sure that's desired...
> >
> > Well if sha1 is supposed to be forbidden in FIPS mode why should
>
> SHA-1 is approved in all use cases except signatures.

Actually, even that's not quite true: you can't use it in a FIPS
compliant system to *generate* signatures, but you can still use it in
a FIPS compliant system to verify legacy signatures (signatures created
before sha-1 was deprecated). It's still also completely acceptable as
a hash for HMAC.

The supporting document is this one:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf

The bottom line is removing SHA-1 to achieve "FIPS compliance" is the
wrong approach. You just have to make sure you can never use it to
generate signatures.

James