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

[Herbert Xu <herbert@gondor.apana.org.au>]

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)).

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt