From: "Stephan Müller" <smueller@chronox.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)
Date: Sat, 18 Mar 2017 09:18:17 +0100 [thread overview]
Message-ID: <17325553.qTOCmu80z1@positron.chronox.de> (raw)
In-Reply-To: <CAHmME9oopUxc3fdRERdhHk=GYJuqAonhRBhmyUQE81fPdLn9Zw@mail.gmail.com>
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
next prev parent reply other threads:[~2017-03-18 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 8:21 [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1) Stephan Müller
2017-03-17 15:31 ` Jason A. Donenfeld
2017-03-18 8:18 ` Stephan Müller [this message]
2017-03-18 10:11 ` Jeffrey Walton
2017-03-18 13:31 ` Stephan Müller
2017-03-18 13:43 ` Jeffrey Walton
2017-03-18 16:36 ` Stephan Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17325553.qTOCmu80z1@positron.chronox.de \
--to=smueller@chronox.de \
--cc=Jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox