On Thu, Apr 8, 2021 at 8:52 AM Hangbin Liu <liuhangbin@xxxxxxxxx> wrote: > On Wed, Apr 07, 2021 at 03:15:51PM -0600, Jason A. Donenfeld wrote: > > Hi Hangbin, > > > > On Wed, Apr 7, 2021 at 5:39 AM Hangbin Liu <liuhangbin@xxxxxxxxx> 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? > > Hi Jason, > > I'm not familiar with the crypto code. From wg_noise_init() it looks the init > part is in header file. So I just disabled wireguard directly. > > For disabling the modules. Hi Ondrej, do you know if there is any FIPS policy > in crypto part? There seems no handler when load not allowed crypto modules > in FIPS mode. If I understand your question correctly, yes, there is a mechanism that disables not-FIPS-approved algorithms/drivers in FIPS mode (not kernel modules themselves, AFAIK). So if any part of the kernel tries to use e.g. chacha20 via the Crypto API (the bits in crypto/...), it will fail. I'm not sure about the direct library interface (the bits in lib/crypto/...) though... That's relatively new and I haven't been following the upstream development in this area that closely for some time now... > > BTW, I also has a question, apart from the different RFC standard, what's the > relation/difference between crypto/chacha20poly1305.c and lib/crypto/chacha20poly1305.c? > > Thanks > Hangbin > -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
