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

[Jeff Barnes]

On 3/1/26 15:41, Joachim Vandersmissen wrote:
> 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.


For instance, ceph, samba, tls, to name a few. They all instantiate the 
gcm(aes) template. They all construct their own IV. They are all 
compliant to SP 800-38d. I am pretty sure that at least one constructs 
it per 8.2.2 while the rest construct per 8.2.1.

There is a good case for asserting "the kernel crypto api is FIPS 
compliant, for out-of-tree modules, you're on your own". But that's 
where the need for the service indicator arises. I'm sure that 
maintaining the out-of-tree patch with a service indicator is a royal 
pain downstream.


> > 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,