linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	labbott@redhat.com
Subject: Re: [PATCH] random: addu a config option to trust the CPU's hwrng
Date: Wed, 18 Jul 2018 13:36:21 -0400	[thread overview]
Message-ID: <20180718173621.GC30706@thunk.org> (raw)
In-Reply-To: <CACXcFmk7D5t9yg9VxhKZgMvqK-LmFF0d7Dh9A3hsoGTfzzeM8A@mail.gmail.com>

On Wed, Jul 18, 2018 at 11:14:20AM -0400, Sandy Harris wrote:
> Instead, I had a compile-time option to choose a number 0-32
> for how much entropy to assume a 32-bit value from the HWRNG
> contains. Default was something less than 32. I debated values
> in the 24-30 range, don't recall what I chose & don't think it
> Matters hugely.
> 
> Is that a better approach than the binary choice?

This patch is only affecting the initialization of the CRNG.  It
doesn't do anything about the entropy estimator, so it doesn't change
the behavior of /dev/random, for example.

In practice I doubt most people would be able to deal with a numerical
dial, and I'm trying to ecourage people to use getrandom(2).  I view
/dev/random as a legacy interface, and for most people a CRNG is quite
sufficient.  For those people who are super paranoid and want a "true
random number generator" (and the meaning of that is hazy) because a
CRNG is Not Enough, my recommendation these days is that they get
something like an open hardware RNG solution, such as ChaosKey from
Altus Metrum[1].

[1] https://altusmetrum.org/ChaosKey/

						- Ted

  reply	other threads:[~2018-07-18 17:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18  1:43 [PATCH] random: add a config option to trust the CPU's hwrng Theodore Ts'o
2018-07-18  1:51 ` Theodore Y. Ts'o
2018-07-18 15:14   ` Sandy Harris
2018-07-18 17:36     ` Theodore Y. Ts'o [this message]
2018-07-18 20:22       ` [PATCH] random: addu " Sandy Harris
2018-07-19 14:21         ` Theodore Y. Ts'o
2018-07-19 20:17       ` Yann Droneaud
2018-07-18 17:36   ` [PATCH] random: add " Ken Moffat
2018-07-19  0:19     ` Ken Moffat
2018-07-18  5:09 ` Randy Dunlap
2018-07-18  6:46 ` Jeffrey Walton
2018-07-18  7:22 ` Yann Droneaud
2018-07-18 14:26   ` Theodore Y. Ts'o
2018-07-18 15:29     ` Yann Droneaud
2018-07-18 19:17       ` Theodore Y. Ts'o
2018-08-04 21:52     ` Pavel Machek
2018-08-05  0:25       ` Theodore Y. Ts'o
2018-08-05  0:28         ` Theodore Y. Ts'o
2018-08-05  9:44         ` Pavel Machek
2018-07-20 19:09 ` Laura Abbott

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=20180718173621.GC30706@thunk.org \
    --to=tytso@mit.edu \
    --cc=labbott@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandyinchina@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).