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
