Re: [PATCH] crypto: aead: add service indicator flag for RFC4106 AES-GCM
From: Jeff Barnes
Date: Tue Feb 17 2026 - 16:00:00 EST
On 1/30/26 00:10, Herbert Xu wrote:
On Thu, Jan 29, 2026 at 04:04:36PM -0500, jeffbarnes@xxxxxxxxxxxxxxxxxxx wrote:
From: Jeff Barnes <jeffbarnes@xxxxxxxxxxxxx>Rather than exporting this indicator, I would prefer that we just
FIPS 140 validations require a “service indicator” to positively
identify when an approved cryptographic service is provided. For
RFC4106 AES‑GCM (used by IPsec), this commit exposes a per‑request
indicator bit when the IV/nonce construction meets the FIPS uniqueness
requirement.
Specifically, the indicator is set when the caller uses the RFC4106
construction with seqiv (per RFC 4106 §3), where the 32‑bit salt and
64‑bit seqiv together guarantee a unique 96‑bit IV per key. This
meets the SP 800‑38D §8.2 uniqueness requirement for GCM.
No ABI or uAPI changes. The flag is internal to the crypto API request
path and may be consumed by in‑tree callers that need to record service
use in a FIPS context.
Tests:
- Verified that gcm(aes) requests never set the service‑indicator bit.
- Verified that rfc4106(gcm(aes)) requests consistently set the bit.
- Existing crypto self‑tests continue to pass.
- checkpatch.pl: no issues.
Signed-off-by: Jeff Barnes <jeffbarnes@xxxxxxxxxxxxx>
forbid non-compliant combinations when FIPS mode is enabled.
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.
Thanks,