netdev - Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 08 Apr 2021 09:55:15 -0400
From:   Simo Sorce <simo@...hat.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Hangbin Liu <liuhangbin@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode

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 <liuhangbin@...il.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