[PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

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:
>>> Hi Thomas,
>>>
>>> On 9/9/26 9:36 AM, Thomas Huth wrote:
>>>> On 15/03/2026 01.43, Joachim Vandersmissen wrote:
>>>>> Hi Herbert,
>>>>>
>>>>> 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.
>>>> Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway?
>>>> 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?
>>> There is a risk that users may not know that xxhash64 is not FIPS
>>> compliant and would still use it. Especially considering it was marked
>>> as "fips_allowed = 1" for a while.
>> So isn't that a very bad situation? They think they are FIPS compliant, but
>> 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?
> As described in the dm-integrity documentation, dm-integrity supports
> 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