On Wed, 2021-04-07 at 15:15 -0600, Jason A. Donenfeld wrote:

Hi Hangbin,

On Wed, Apr 7, 2021 at 5:39 AM Hangbin Liu [off-list ref] wrote:

quoted

As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
FIPS certified, the WireGuard module should be disabled in FIPS mode.

I'm not sure this makes so much sense to do _in wireguard_. If you
feel like the FIPS-allergic part is actually blake, 25519, chacha, and
poly1305, then wouldn't it make most sense to disable _those_ modules
instead? And then the various things that rely on those (such as
wireguard, but maybe there are other things too, like
security/keys/big_key.c) would be naturally disabled transitively?

The reason why it is better to disable the whole module is that it
provide much better feedback to users. Letting init go through and then
just fail operations once someone tries to use it is much harder to
deal with in terms of figuring out what went wrong.
Also wireguard seem to be poking directly into the algorithms
implementations and not use the crypto API, so disabling individual
algorithm via the regular fips_enabled mechanism at runtime doesn't
work.

[As an aside, I don't think any of this fips-flag-in-the-kernel makes
much sense at all for anything, but that seems like a different
discussion, maybe?]

It makes sense, because vendors provide a single kernel that can be
used by both people that are required to be FIPS compliant and people
that don't. For people that are required to be FIPS complaint vendors
want to provide the ability to use a single knob (fips=1 at boot) to
turn off everything that is not FIPS compliant.
Disabling algorithms at compile time would not work for people that do
not care about FIPS compliance.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc