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

[Jeff Barnes <jeffbarnes@linux.microsoft.com>]

On 3/2/26 22:37, Herbert Xu wrote:
> On Mon, Mar 02, 2026 at 04:51:38PM -0500, Jeff Barnes wrote:
>>
>> 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.
> 
> Perhaps they could switch to IV generation in a way that's similar
> to seqiv?
Actually, there's no need to do that. They are all compliant already 
with the spec.

The issue according to the CMVP (NIST) is that because the kernel crypto 
api is, well, an api, that it is *possible* to instantiate the gcm(aes) 
template and generate an IV in a non-compliant way. Even when pressing 
the point that the kernel is monolithic, hence self-contained, and 
booted with lockdown=integrity, the point is lost on the certifying 
body. Their response is to implement the service indicator "like all the 
other distros". That is a very unfortunate way of putting it. It is what 
it is.

So currently, for the kernel (crypto api) to pass FIPS 140-3 
certification, the only viable solution is to either implement the 
out-of-tree patch or disallow gcm(aes) in FIPS mode. Of the two, the 
out-of-tree patch is expensive but the lesser of the two evils.

I like the idea of automatically switching to seqiv or rfc4106 templates 
when in FIPS mode. The unfortunate consequence is scale. There are 24 
gcm(aes) template instantiations spread out through the kernel tree with 
about as many maintainers. Each of them generate an IV. That seems to me 
to be too large scale.

Please reconsider.

Best regards,
Jeff

> 
> Cheers,