Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode
From: Joachim Vandersmissen
Date: Thu Sep 10 2026 - 22:55:55 EST
Hi Eric,
On 9/10/26 9:14 AM, Eric Biggers wrote:
On Thu, Sep 10, 2026 at 10:57:32AM +0200, Thomas Huth wrote:
On 10/09/2026 05.24, Joachim Vandersmissen wrote:As described in the dm-integrity documentation, dm-integrity supports
Hi Thomas,So isn't that a very bad situation? They think they are FIPS compliant, but
On 9/9/26 9:36 AM, Thomas Huth wrote:
On 15/03/2026 01.43, Joachim Vandersmissen wrote:There is a risk that users may not know that xxhash64 is not FIPS
Hi Herbert,Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway?
I don't think this one can be applied yet since dm-integrity
still uses xxhash64 through the crypto API. This would break
fips=1 systems that use it.
If xxhash64 isn't FIPS-compliant, nobody should use it for
dm-integrity there, right? So I doubt that there are any systems out
there that use fips=1 and use xxhash64 at the same time?
compliant and would still use it. Especially considering it was marked
as "fips_allowed = 1" for a while.
actually they are not since they use an unapproved algorithm by accident.
Maybe it would be better to include this patch so that they are aware of the
mistake? If there is really somebody running into this issue, they could
boot once with fips=0, fix their system, reboot again with fips=1 and
finally be really compliant. Sounds like the better solution to me. WDYT?
non-cryptographic checksums for protection from accidental corruption.
That use case is no different from any other use case of a checksum.
It's also no different from using crc32 or crc32c, which similarly have
fips_allowed=1 and this patch completely ignores.
The solution is not banning checksums or making any other code change,
but rather just doing what it seems everyone has already been doing:
documenting in their FIPS security policy that checksums are only for
use cases that are not "security functions".
Unfortunately, this is not an option anymore due to the opinion of the CMVP that was issued back in March. If you have an account (you can sign up for free), you can read it in full here: https://cmuf-workspace.org/Products/Projects/Messages.aspx?prjID=3&id=559. I can also send a copy of the PDF file privately, if necessary.
The relevant text is:
1.a. Can xxhash64 be used in approved mode as non-security function without any further action (in this case FIPS IG 2.4.A will not be applicable)?
Answer: No, xxhash64 cannot be understood as a non-security function because:
1) It is offered as an equivalent hash alternative to approved hash algorithms (i.e., SHA) using the same interface/API and therefore appears to an operator that it can provide cryptographic protection (i.e., security).
2) Its return value (i.e., mode indicator) is the same as for approved cryptographic functions that provide security.
3) It is accessed by an interface/API that has “crypto” in the name and thus implies security.
4) It is an available hash function (i.e. PRF) of HMAC, which is a keyed algorithm that implies security.
crc32 and crc32c were not explicitly called out in the resolution, which is why this patch didn't target them. Though following the same rationale, they should also be disabled.
- Eric