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

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

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,