linux-kernel - Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

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]

Message-ID: <17325553.qTOCmu80z1@positron.chronox.de>
Date:   Sat, 18 Mar 2017 09:18:17 +0100
From:   Stephan Müller <smueller@...onox.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Am Freitag, 17. März 2017, 16:31:29 CET schrieb Jason A. Donenfeld:

Hi Jason,

> Hey Stephan,
> 
> Have you considered submitting this without so many options? For
> example -- just unconditionally using ChaCha20 instead of the
> configurable crypto API functions? And either removing the FIPS140
> compliance code, and either unconditionally including it, or just
> getting rid of it? And finally just making this a part of the kernel
> directly, instead of adding this as a standalone optional component?

Submitting that with various options removed is no problem as the core concept 
of my implementation is to be flexible to allow folks to easily add new noise 
sources or a DRNG replacement.

Yet, there are reasons for the different options:

- some folks want to use a known good and proven DRNG for post-processing 
(hence the offer for using an SP800-90A DRBG)

- some folks want a DRNG that is not tied to the kernel crypto API (hence the 
offer for the ChaCha20 DRNG)

- some folks need the FIPS continuous self test and some do not.

The idea for the solution in the LRNG code is that a user shall not be 
involved with these compile-time decisions. All options that are present are 
based on other kernel configuration options:

- if the kernel crypto API is present and the SP800-90A DRBG is compiled, then 
the LRNG uses the SP800-90A DRBG

- as a user may compile in different types of the SP800-90A DRBG, the LRNG 
will use the one that is available

- if no kernel crypto API is compiled, it uses the ChaCha20 DRNG

- if FIPS support is not compiled, the FIPS continuous test is not compiled

Thus, a user does not get in touch with all the options in the LRNG code. 
Shouldn't that be a good argument to keep these options?

I would like to add the LRNG code directly to the kernel and I can offer an 
official patch instead of such out-of-tree code. However, in the past I got 
shot down when I suggested an inclusion.

Ciao
Stephan