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

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

[jeffbarnes]

From: Jeff Barnes <jeffbarnes@microsoft.com>

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@microsoft.com>
---
This series introduces a service indicator for AES-GCM to support
deployments that require FIPS 140 validation.  The Linux kernel
currently exposes no explicit mechanism for callers to determine
whether an AEAD construction is operating in a configuration suitable
for validated use.

The patch adds a gcm indicator allowing user space and in-kernel
consumers to distinguish between validated and non-validated modes.

For AES-GCM, the indicator is set for the RFC4106 construction used
in, for example, IPsec and remains unset for the generic gcm(aes)
template, which aligns with expected FIPS usage.

Testing shows that with this change, gcm(aes) does not report the
indicator, while rfc4106(gcm(aes)) does.  No functional behavior is
modified for existing callers, and no regressions were observed in test
coverage.
---
 crypto/aead.c            | 12 ++++++++++--
 include/crypto/rfc4106.h | 20 ++++++++++++++++++++
 include/linux/crypto.h   |  2 ++
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/crypto/aead.c b/crypto/aead.c
index e009937bf3a5d946e1de31257131940b2bc636fe..dcc0562b395ba9a8eb15fe9fa679b27e8b9db5d5 100644
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -8,6 +8,7 @@
  */
 
 #include <crypto/internal/aead.h>
+#include <crypto/rfc4106.h>
 #include <linux/cryptouser.h>
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -46,6 +47,7 @@ int crypto_aead_setkey(struct crypto_aead *tfm,
 {
 	unsigned long alignmask = crypto_aead_alignmask(tfm);
 	int err;
+	const char *name;
 
 	if ((unsigned long)key & alignmask)
 		err = setkey_unaligned(tfm, key, keylen);
@@ -58,6 +60,12 @@ int crypto_aead_setkey(struct crypto_aead *tfm,
 	}
 
 	crypto_aead_clear_flags(tfm, CRYPTO_TFM_NEED_KEY);
+	name = crypto_tfm_alg_name(&tfm->base);
+	if (name && rfc4106_keysize_ok(keylen) &&
+		(!strcmp(name, "rfc4106(gcm(aes))") ||
+		!strcmp(name, "seqiv(gcm(aes))")))
+		crypto_aead_set_flags(tfm, CRYPTO_TFM_FIPS_COMPLIANCE);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(crypto_aead_setkey);
@@ -156,13 +164,13 @@ static void __maybe_unused crypto_aead_show(struct seq_file *m,
 {
 	struct aead_alg *aead = container_of(alg, struct aead_alg, base);
 
-	seq_printf(m, "type         : aead\n");
+	seq_puts(m, "type         : aead\n");
 	seq_printf(m, "async        : %s\n",
 		   str_yes_no(alg->cra_flags & CRYPTO_ALG_ASYNC));
 	seq_printf(m, "blocksize    : %u\n", alg->cra_blocksize);
 	seq_printf(m, "ivsize       : %u\n", aead->ivsize);
 	seq_printf(m, "maxauthsize  : %u\n", aead->maxauthsize);
-	seq_printf(m, "geniv        : <none>\n");
+	seq_puts(m, "geniv        : <none>\n");
 }
 
 static void crypto_aead_free_instance(struct crypto_instance *inst)
diff --git a/include/crypto/rfc4106.h b/include/crypto/rfc4106.h
new file mode 100644
index 0000000000000000000000000000000000000000..96e50bc38b63a26106d979221288af5726ae4deb
--- /dev/null
+++ b/include/crypto/rfc4106.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _CRYPTO_RFC4106_H
+#define _CRYPTO_RFC4106_H
+
+#include <crypto/aes.h>
+
+#define RFC4106_SALT_SIZE		4
+
+#define RFC4106_AEAD_KEYSIZE_128	(RFC4106_SALT_SIZE + AES_KEYSIZE_128) /* 20 */
+#define RFC4106_AEAD_KEYSIZE_192	(RFC4106_SALT_SIZE + AES_KEYSIZE_192) /* 28 */
+#define RFC4106_AEAD_KEYSIZE_256	(RFC4106_SALT_SIZE + AES_KEYSIZE_256) /* 36 */
+
+static inline bool rfc4106_keysize_ok(unsigned int keylen)
+{
+	return keylen == RFC4106_AEAD_KEYSIZE_128 ||
+		keylen == RFC4106_AEAD_KEYSIZE_192 ||
+		keylen == RFC4106_AEAD_KEYSIZE_256;
+}
+
+#endif /* _CRYPTO_RFC4106_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index a2137e19be7d86846633e6d7acca6dec59e98c77..56432af271f24ea74f687707883fa77f3a45a5d9 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -152,6 +152,8 @@
 #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
 #define CRYPTO_TFM_REQ_ON_STACK		0x00000800
 
+#define CRYPTO_TFM_FIPS_COMPLIANCE      0x80000000
+
 /*
  * Miscellaneous stuff.
  */

---
base-commit: c66e0a273f223fe38b8b72c034857622b0651482
change-id: 20260129-fips-gcm-clean-v1-9456700aa29c

Best regards,
-- 
Jeff Barnes <jeffbarnes@microsoft.com>

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

[Herbert Xu]

On Thu, Jan 29, 2026 at 04:04:36PM -0500, jeffbarnes@linux.microsoft.com wrote:
> From: Jeff Barnes <jeffbarnes@microsoft.com>
> 
> 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@microsoft.com>

Rather than exporting this indicator, I would prefer that we just
forbid non-compliant combinations when FIPS mode is enabled.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Jeff Barnes]

On 1/30/26 00:10, Herbert Xu wrote:
> On Thu, Jan 29, 2026 at 04:04:36PM -0500, jeffbarnes@linux.microsoft.com wrote:
>> From: Jeff Barnes <jeffbarnes@microsoft.com>
>>
>> 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@microsoft.com>
> Rather than exporting this indicator, I would prefer that we just
> 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,

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

[Herbert Xu]

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@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Joachim Vandersmissen]

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.

However, Cryptographic Module Validation Program has also recently made 
it clear that xxhash64 cannot be FIPS approved the way it is currently 
implemented in the kernel. Even though the designers of xxhash publicly 
state that it is a non-cryptographic hash, the kernel offers it as part 
of the shash interface, the same interface as the approved algorithms. 
The interface / API also has "crypto" in the name, which according to 
CMVP implies security. CMVP feels that there could be confusion with the 
approved hash algorithms, so there needs to be some indication that 
xxhash64 is not FIPS approved. I think blocking xxhash64 in FIPS mode 
would break btrfs, where it is used for checksumming.

Kind regards,
Joachim

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

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

[Herbert Xu]

On Sun, Mar 01, 2026 at 02:41:28PM -0600, Joachim Vandersmissen wrote:
>
> However, Cryptographic Module Validation Program has also recently made it
> clear that xxhash64 cannot be FIPS approved the way it is currently
> implemented in the kernel. Even though the designers of xxhash publicly
> state that it is a non-cryptographic hash, the kernel offers it as part of
> the shash interface, the same interface as the approved algorithms. The
> interface / API also has "crypto" in the name, which according to CMVP
> implies security. CMVP feels that there could be confusion with the approved
> hash algorithms, so there needs to be some indication that xxhash64 is not
> FIPS approved. I think blocking xxhash64 in FIPS mode would break btrfs,
> where it is used for checksumming.

xxhash64 should be converted to lib/crypto and removed from the
Crypto API.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Jeff Barnes]

On 3/2/26 07:26, Herbert Xu wrote:
> On Sun, Mar 01, 2026 at 02:41:28PM -0600, Joachim Vandersmissen wrote:
>> However, Cryptographic Module Validation Program has also recently made it
>> clear that xxhash64 cannot be FIPS approved the way it is currently
>> implemented in the kernel. Even though the designers of xxhash publicly
>> state that it is a non-cryptographic hash, the kernel offers it as part of
>> the shash interface, the same interface as the approved algorithms. The
>> interface / API also has "crypto" in the name, which according to CMVP
>> implies security. CMVP feels that there could be confusion with the approved
>> hash algorithms, so there needs to be some indication that xxhash64 is not
>> FIPS approved. I think blocking xxhash64 in FIPS mode would break btrfs,
>> where it is used for checksumming.
> xxhash64 should be converted to lib/crypto and removed from the
> Crypto API.
>
> Thanks,


I believe Eric Biggers commitfe11ac191ce0ad910f6fda0c628bcff19fcff47d 
did this already.
Best,
Jeff

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,

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

[Herbert Xu]

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?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Christoph Hellwig]

On Mon, Mar 02, 2026 at 04:51:38PM -0500, Jeff Barnes wrote:
> 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.

And that's a good thing.  Maintaining out of tree stuff should be a
royal pain and not impact the upstream kernel in any way.

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

[Jeff Barnes]

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,

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

[Eric Biggers]

On Thu, Mar 12, 2026 at 10:00:59AM -0400, Jeff Barnes wrote:
> 
> 
> 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.

This whole exercise seems awfully silly, given that no code is actually
going to check the CRYPTO_TFM_FIPS_COMPLIANCE flag, either upstream or
downstream.  So this is just unused code which exists only to satisfy a
check box for something that FIPS 140 says has to be there but is never
used in practice.  While upstream does have limited support for FIPS
140, that limited support tends to be for things which at least actually
do *something*, not completely unused code.

I guess I have to ask, if the theoretical possibility of code calling
'crypto_tfm_get_flags(tfm) & CRYPTO_TFM_FIPS_COMPLIANCE' is sufficient
to count as a service indicator for AES-GCM, is there any reason why the
procedure for retrieving the service indicator can't be something like
'strncmp("seqiv(", crypto_tfm_alg_name(tfm), 6) == 0'?  That would
effectively be the same thing, and it wouldn't require any new code.

If that's not enough and your FIPS certification lab will only accept
the solution with unused code, I don't think that's very compatible with
upstream, sorry.  Any unused code upstream is going to tend to be
removed, as per the usual kernel development practices.

- Eric