FIPS requirements in lib/crypto/ APIs

FIPS requirements in lib/crypto/ APIs

[Joachim Vandersmissen]

Hi Eric,

I'm starting a new thread since I don't want to push the SHAKE256 thread 
off-topic too much.

One simple example of a FIPS requirement that I currently don't see in 
lib/crypto/ is that HMAC keys must be at least 112 bits in length. If 
the lib/crypto/ HMAC API wants to be FIPS compliant, it must enforce 
that (i.e., disallow HMAC computations using those small keys). It's 
trivial to add a check to __hmac_sha1_preparekey or hmac_sha1_preparekey 
or hmac_sha1_init_usingrawkey, but the API functions don't return an 
error code. How would the caller know anything is wrong? Maybe there 
needs to be a mechanism in place first to let callers know about these 
kinds of checks?

It would be great to have your guidance since you've done so much work 
on the lib/crypto/ APIs, you obviously know the design very well.

Kind regards,
Joachim

Re: FIPS requirements in lib/crypto/ APIs

[Eric Biggers]

On Thu, Sep 18, 2025 at 11:00:45AM -0500, Joachim Vandersmissen wrote:
> Hi Eric,
> 
> I'm starting a new thread since I don't want to push the SHAKE256 thread
> off-topic too much.
> 
> One simple example of a FIPS requirement that I currently don't see in
> lib/crypto/ is that HMAC keys must be at least 112 bits in length. If the
> lib/crypto/ HMAC API wants to be FIPS compliant, it must enforce that (i.e.,
> disallow HMAC computations using those small keys). It's trivial to add a
> check to __hmac_sha1_preparekey or hmac_sha1_preparekey or
> hmac_sha1_init_usingrawkey, but the API functions don't return an error
> code. How would the caller know anything is wrong? Maybe there needs to be a
> mechanism in place first to let callers know about these kinds of checks?
> 
> It would be great to have your guidance since you've done so much work on
> the lib/crypto/ APIs, you obviously know the design very well.

That's misleading.  First, in the approach to FIPS certification that is
currently (sort of) supported by the upstream kernel, the FIPS module
contains the entire kernel.  lib/crypto/ contains kernel-internal
functions, which are *not* part of the interface of the FIPS module.
So, lib/crypto/ does *not* need to have a "FIPS compliant API".

Second, according to the document "Implementation Guidance for FIPS
140-3 and the Cryptographic Module Validation Program", HMAC with keys
shorter than 112 bits is still approved for legacy use in verifying
existing messages.

Third, HMAC is sometimes used with HKDF, where the input keying material
is passed as the *data*.  The HMAC key length would be the wrong length
to check in this case.

Fourth, not every user of HMAC is the kernel is necessarily for a
"security function" of the FIPS module.  Non-security functions can use
non-FIPS-approved algorithms.

Point is: lib/crypto/ is correct in allowing HMAC keys shorter than 112
bits.  (And this is a lot like how lib/ also has entirely
non-FIPS-approved algorithms, like ChaCha20...)  It's up to callers of
the hmac_*() functions, who have more information about the purpose for
which HMAC is actually being used, to do the check *if* they need it.

- Eric

Re: FIPS requirements in lib/crypto/ APIs

[Joachim Vandersmissen]

Hi Eric,

On 9/18/25 11:33 AM, Eric Biggers wrote:
> On Thu, Sep 18, 2025 at 11:00:45AM -0500, Joachim Vandersmissen wrote:
>> Hi Eric,
>>
>> I'm starting a new thread since I don't want to push the SHAKE256 thread
>> off-topic too much.
>>
>> One simple example of a FIPS requirement that I currently don't see in
>> lib/crypto/ is that HMAC keys must be at least 112 bits in length. If the
>> lib/crypto/ HMAC API wants to be FIPS compliant, it must enforce that (i.e.,
>> disallow HMAC computations using those small keys). It's trivial to add a
>> check to __hmac_sha1_preparekey or hmac_sha1_preparekey or
>> hmac_sha1_init_usingrawkey, but the API functions don't return an error
>> code. How would the caller know anything is wrong? Maybe there needs to be a
>> mechanism in place first to let callers know about these kinds of checks?
>>
>> It would be great to have your guidance since you've done so much work on
>> the lib/crypto/ APIs, you obviously know the design very well.
> That's misleading.  First, in the approach to FIPS certification that is
> currently (sort of) supported by the upstream kernel, the FIPS module
> contains the entire kernel.  lib/crypto/ contains kernel-internal
> functions, which are *not* part of the interface of the FIPS module.
> So, lib/crypto/ does *not* need to have a "FIPS compliant API".

Please correct me if I'm wrong, but are the lib/crypto/ APIs not 
exported for everyone to use? Even if the entire kernel is the FIPS 
module, wouldn't that mean the APIs could be used by e.g. dynamically 
loaded kernel modules?

You are right there are some nuances about the HMAC key lengths, as with 
most FIPS requirements. There's other FIPS requirements, like tag sizes 
for HMAC, or IV generation for AES-GCM encryption, that also have very 
similar nuances.

I'm more trying to figure out a general approach to address these kinds 
of requirements. What I usually see in FIPS modules, is that the FIPS 
module API is as conservative as possible, rather than relying on the 
callers to perform the FIPS requirement checks.

>
> Second, according to the document "Implementation Guidance for FIPS
> 140-3 and the Cryptographic Module Validation Program", HMAC with keys
> shorter than 112 bits is still approved for legacy use in verifying
> existing messages.
>
> Third, HMAC is sometimes used with HKDF, where the input keying material
> is passed as the *data*.  The HMAC key length would be the wrong length
> to check in this case.
>
> Fourth, not every user of HMAC is the kernel is necessarily for a
> "security function" of the FIPS module.  Non-security functions can use
> non-FIPS-approved algorithms.
>
> Point is: lib/crypto/ is correct in allowing HMAC keys shorter than 112
> bits.  (And this is a lot like how lib/ also has entirely
> non-FIPS-approved algorithms, like ChaCha20...)  It's up to callers of
> the hmac_*() functions, who have more information about the purpose for
> which HMAC is actually being used, to do the check *if* they need it.
>
> - Eric
>

Re: FIPS requirements in lib/crypto/ APIs

[Eric Biggers]

On Thu, Sep 18, 2025 at 12:48:52PM -0500, Joachim Vandersmissen wrote:
> Hi Eric,
> 
> On 9/18/25 11:33 AM, Eric Biggers wrote:
> > On Thu, Sep 18, 2025 at 11:00:45AM -0500, Joachim Vandersmissen wrote:
> > > Hi Eric,
> > > 
> > > I'm starting a new thread since I don't want to push the SHAKE256 thread
> > > off-topic too much.
> > > 
> > > One simple example of a FIPS requirement that I currently don't see in
> > > lib/crypto/ is that HMAC keys must be at least 112 bits in length. If the
> > > lib/crypto/ HMAC API wants to be FIPS compliant, it must enforce that (i.e.,
> > > disallow HMAC computations using those small keys). It's trivial to add a
> > > check to __hmac_sha1_preparekey or hmac_sha1_preparekey or
> > > hmac_sha1_init_usingrawkey, but the API functions don't return an error
> > > code. How would the caller know anything is wrong? Maybe there needs to be a
> > > mechanism in place first to let callers know about these kinds of checks?
> > > 
> > > It would be great to have your guidance since you've done so much work on
> > > the lib/crypto/ APIs, you obviously know the design very well.
> > That's misleading.  First, in the approach to FIPS certification that is
> > currently (sort of) supported by the upstream kernel, the FIPS module
> > contains the entire kernel.  lib/crypto/ contains kernel-internal
> > functions, which are *not* part of the interface of the FIPS module.
> > So, lib/crypto/ does *not* need to have a "FIPS compliant API".
> 
> Please correct me if I'm wrong, but are the lib/crypto/ APIs not exported
> for everyone to use? Even if the entire kernel is the FIPS module, wouldn't
> that mean the APIs could be used by e.g. dynamically loaded kernel modules?
>
> You are right there are some nuances about the HMAC key lengths, as with
> most FIPS requirements. There's other FIPS requirements, like tag sizes for
> HMAC, or IV generation for AES-GCM encryption, that also have very similar
> nuances.
> 
> I'm more trying to figure out a general approach to address these kinds of
> requirements. What I usually see in FIPS modules, is that the FIPS module
> API is as conservative as possible, rather than relying on the callers to
> perform the FIPS requirement checks.

Aren't these distros including the modules within their FIPS module
boundary too?  It seems they would need to.

Either way, they've been getting their FIPS certificates despite lib/
including non-FIPS-approved stuff for many years.  So it can't be that
much of an issue in practice.

- Eric

Re: FIPS requirements in lib/crypto/ APIs

[Theodore Ts'o]

On Thu, Sep 18, 2025 at 01:06:47PM -0500, Eric Biggers wrote:
> > I'm more trying to figure out a general approach to address these kinds of
> > requirements. What I usually see in FIPS modules, is that the FIPS module
> > API is as conservative as possible, rather than relying on the callers to
> > perform the FIPS requirement checks.
> 
> Aren't these distros including the modules within their FIPS module
> boundary too?  It seems they would need to.
> 
> Either way, they've been getting their FIPS certificates despite lib/
> including non-FIPS-approved stuff for many years.  So it can't be that
> much of an issue in practice.

What I would recommend for those people who need FIPS certification
(which is a vanishingly small percentage of Linux kernel users, BTW),
that the FIPS module use their own copy of the crypto algorithms, and
*not* depend on kernel lib/crypto interfaces.

Why?  Because FIPS certification is on the binary artifact, and if
there is a high-severity vulnerability. if you are selling into the US
Government market, FEDRAMP requires that you mitigate that
vulnerability within 30 days and that will likely require that you
deploy a new kernel binary.

So it would be useful if the FIPS module doesn't need to change when
your FEDRAMP certification officer requires that you update the
kernel, and if the FIPS module is "the whole kernel", addressing the
high-severity CVE would break the FIPS certification.  So it really is
much better if you can decouple the FIPS module from the rest of the
kernel, since otherwise the FIPS certification mandate and the FEDRAMP
certification mandate could put you in a very uncomfortable place.

It's also why historically many companies who need to provide FIPS
certification will carefully architect their solution so it is only
dependent on userspace crypto.  A number of years ago, I was involved
in a project at a former employer where we separated the crypto core
of the OpenSSL library from the rest of OpenSSL, so that when there
was a buffer overrun in the ASN.1 DER decoding of a certificate (for
example), we could fix it without breaking the FIPS certification of
the crypto core.  And we didn't even *consider* trying add a kernel
crypto dependency.

One of the important things to remember is that as far as FIPS
certification is concerned, the existence of remote privilege attacks
don't matter, so long as you meet all of the FIPS certification
security theatre.  But in the real world, you really want to fix high
severity CVE's....

Cheers,

					- Ted

Re: FIPS requirements in lib/crypto/ APIs

[Jeff Barnes]

On 9/19/25 11:22, Theodore Ts'o wrote:
> On Thu, Sep 18, 2025 at 01:06:47PM -0500, Eric Biggers wrote:
>>> I'm more trying to figure out a general approach to address these kinds of
>>> requirements. What I usually see in FIPS modules, is that the FIPS module
>>> API is as conservative as possible, rather than relying on the callers to
>>> perform the FIPS requirement checks.
>> Aren't these distros including the modules within their FIPS module
>> boundary too?  It seems they would need to.
>>
>> Either way, they've been getting their FIPS certificates despite lib/
>> including non-FIPS-approved stuff for many years.  So it can't be that
>> much of an issue in practice.
> What I would recommend for those people who need FIPS certification
> (which is a vanishingly small percentage of Linux kernel users, BTW),
> that the FIPS module use their own copy of the crypto algorithms, and
> *not* depend on kernel lib/crypto interfaces.
>
> Why?  Because FIPS certification is on the binary artifact, and if
> there is a high-severity vulnerability. if you are selling into the US
> Government market, FEDRAMP requires that you mitigate that
> vulnerability within 30 days and that will likely require that you
> deploy a new kernel binary.
That *must* not be the recommendation of the kernel crypto team. Why 
bother developing and deploying a kernel that boots in fips mode at all 
if you recommend users not use it? More below.
>
> So it would be useful if the FIPS module doesn't need to change when
> your FEDRAMP certification officer requires that you update the
> kernel, and if the FIPS module is "the whole kernel", addressing the
> high-severity CVE would break the FIPS certification.  So it really is
> much better if you can decouple the FIPS module from the rest of the
> kernel, since otherwise the FIPS certification mandate and the FEDRAMP
> certification mandate could put you in a very uncomfortable place.

While the FIPS module is "the whole kernel", re-validation for most 
types of kernel upgrades may not prompt a full submission for FIPS 
certification. A CVE re-validation can be as simple as re-filing a 
description of the change to the module or worst case, a re-test of any 
crypto functions that were changed to support the CVE fix. The most 
expensive re-validation (other than a full submission) is the UPDT 
re-validation submission. In either case, the overhead of the 
re-validation is mostly with the CSTL, not with the government. The 
lion's share of the time for a FIPS 140-3 FS (full submission) 
certificate comes *after* the CSTL submits the validation to NIST.

And to be clear, the FedRAMP requirement is that FIPS certifications or 
re-validation be *filed* (not awarded) within 6 months of release of the 
crypto module ("the whole kernel"). The caveat here is that you have to 
have a certificate to file for a re-validation submission. Given NIST 
backlog, it doesn't seem likely that you'll avoid a full submission if 
you don't already have a 140-3 certificate.


> It's also why historically many companies who need to provide FIPS
> certification will carefully architect their solution so it is only
> dependent on userspace crypto.  A number of years ago, I was involved
> in a project at a former employer where we separated the crypto core
> of the OpenSSL library from the rest of OpenSSL, so that when there
> was a buffer overrun in the ASN.1 DER decoding of a certificate (for
> example), we could fix it without breaking the FIPS certification of
> the crypto core.  And we didn't even *consider* trying add a kernel
> crypto dependency.

IMO, this is an optimal solution for a specialized distro; 
general-purpose OS's *should* update and use the actively developed 
crypto api.

BTW, I agree with you that fewer Linux kernel users need to certify at all.

>
> One of the important things to remember is that as far as FIPS
> certification is concerned, the existence of remote privilege attacks
> don't matter, so long as you meet all of the FIPS certification
> security theatre.  But in the real world, you really want to fix high
> severity CVE's....
Please see FedRAMP's differentiation between update stream and 
validation module stream. 
https://www.fedramp.gov/resources/documents/FedRAMP_Policy_for_Cryptographic_Module_Selection_v1.1.0.pdf
>
> Cheers,
>
> 					- Ted