From: Stephan Mueller <smueller@chronox.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Niolai Stange <nstange@suse.com>, Simo Sorce <simo@redhat.com>
Subject: Re: [PATCH] crypto: HMAC - disallow keys < 112 bits in FIPS mode
Date: Tue, 11 Jan 2022 08:17:57 +0100 [thread overview]
Message-ID: <1979340.Ftzpt9979A@tauon.chronox.de> (raw)
In-Reply-To: <2042139.9o76ZdvQCi@positron.chronox.de>
Am Samstag, 8. Januar 2022, 07:39:27 CET schrieb Stephan Müller:
Hi,
> Am Samstag, 8. Januar 2022, 00:28:31 CET schrieb Eric Biggers:
>
> Hi Eric,
>
> > Hi Stephan,
> >
> > On Fri, Jan 07, 2022 at 08:25:24PM +0100, Stephan Müller wrote:
> > > FIPS 140 requires a minimum security strength of 112 bits. This implies
> > > that the HMAC key must not be smaller than 112 in FIPS mode.
> > >
> > > This restriction implies that the test vectors for HMAC that have a key
> > > that is smaller than 112 bits must be disabled when FIPS support is
> > > compiled.
> > >
> > > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> >
> > This could make sense, but the weird thing is that the HMAC code has been
> > like this from the beginning, yet many companies have already gotten this
> > exact same HMAC implementation FIPS-certified. What changed?
>
> FIPS 140-3 (which is now mandatory) requires this based on SP800-131A.
Here are a few more details:
The requirement from FIPS 140-3 that the crypto module (aka kernel crypto API)
must provide an indicator whether the algorithm(s) in use are FIPS compliant.
If you look at various user space libraries, they make quite an effort these
days to add that "service indicator" as an API. Adding such an API to the
crypto API is not helpful.
Thus we revert to the notion of a "global service indicator" meaning that when
the kernel is booted with fips=1, all algorithms operate in FIPS mode. This
means that all non-approved algos must be technically disabled.
There have been patches from me disabling RSA < 2k and others not too long
ago. In the future, I would expect additional patches disabling the use of GCM
when invoked without seqiv or disabling dh when not used with one of the up-
and-coming FFDHE / MODP groups from Nicolai's patch set. All those patches
revolve around the same issue.
Note, for some algorithms like XTS key check we already had such technical
enforcements. This was due to the fact that FIPS 140-2 required for some
aspects technical enforcements but for some others, "procedural" coverage (aka
documentation) was sufficient.
Ciao
Stephan
next prev parent reply other threads:[~2022-01-11 7:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 19:25 [PATCH] crypto: HMAC - disallow keys < 112 bits in FIPS mode Stephan Müller
2022-01-07 23:28 ` Eric Biggers
2022-01-08 6:39 ` Stephan Müller
2022-01-11 7:17 ` Stephan Mueller [this message]
2022-01-28 4:46 ` Herbert Xu
2022-01-28 6:05 ` Stephan Mueller
2022-02-01 8:40 ` [PATCH v2 0/2] " Stephan Müller
2022-02-01 8:40 ` [PATCH v2 1/2] crypto: HMAC - add fips_skip support Stephan Müller
2022-02-01 8:41 ` [PATCH v2 2/2] crypto: HMAC - disallow keys < 112 bits in FIPS mode Stephan Müller
2022-02-11 9:34 ` [PATCH v2 0/2] " Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1979340.Ftzpt9979A@tauon.chronox.de \
--to=smueller@chronox.de \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=nstange@suse.com \
--cc=simo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox