Re: [PATCH] crypto: aead: add service indicator flag for RFC4106 AES-GCM
From: Herbert Xu
Date: Sat Feb 28 2026 - 03:56:46 EST
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@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt