Re: [PATCH] crypto: aead: add service indicator flag for RFC4106 AES-GCM

[Joachim Vandersmissen]

Hi Herbert,

On 2/28/26 2:56 AM, Herbert Xu wrote:
> On Tue, Feb 17, 2026 at 03:59:41PM -0500, Jeff Barnes wrote:
> > I don't know how to accomplish that.
> >
> > SP800-38D provides two frameworks for constructing a gcm IV. (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf)
> >
> > The first construction, described in Sec. 8.2.1, relies on deterministic
> > elements to achieve the uniqueness requirement in Sec. 8; the second
> > construction, described in Sec. 8.2.2, relies on a sufficiently long output
> > string from an approved RBG with a sufficient security strength. My patch
> > checks for an implementation of 8.2.1 via rfc4106(gcm(aes)). I don't know
> > how a patch could check for 8.2.1 or 8.2.2 from an externally generated iv.
> >
> > Suggestions welcome.
> Rather than setting the FIPS_COMPLIANCE flag, why not simply ban the
> non-compliant cases from being used in FIPS mode?
>
> Sure that would mean banning gcm(aes) in FIPS mode, and only
> allowing seqiv(gcm(aes)) but that's OK because we have the
> FIPS_INTERNAL flag to deal with this by only allowing gcm(aes)
> to be used to construct something like seqiv(gcm(aes)).

Like you said, this could work for seqiv(gcm(aes)), if there are truly 
no usecases for gcm(aes) when the kernel is in FIPS mode.

However, Cryptographic Module Validation Program has also recently made 
it clear that xxhash64 cannot be FIPS approved the way it is currently 
implemented in the kernel. Even though the designers of xxhash publicly 
state that it is a non-cryptographic hash, the kernel offers it as part 
of the shash interface, the same interface as the approved algorithms. 
The interface / API also has "crypto" in the name, which according to 
CMVP implies security. CMVP feels that there could be confusion with the 
approved hash algorithms, so there needs to be some indication that 
xxhash64 is not FIPS approved. I think blocking xxhash64 in FIPS mode 
would break btrfs, where it is used for checksumming.

Kind regards,
Joachim

> Of course this would need to be tested since FIPS_INTERNAL was
> introduced for something else but I see no reason why it can't
> be used for gcm too.
>
> Cheers,