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 <liuhang...@gmail.com> wrote: > > 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
