Re: FIPS requirements in lib/crypto/ APIs

[Eric Biggers <ebiggers@kernel.org>]

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