All of
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <>
To: Stephan Mueller <>
Cc: Andy Lutomirski <>,
	Andy Lutomirski <>,
	LKML <>,
	Linux API <>,
	Kees Cook <>,
	"Jason A. Donenfeld" <>,
	"Ahmed S. Darwish" <>,
	Lennart Poettering <>,
	"Eric W. Biederman" <>,
	"Alexander E. Patrakov" <>,
	Michael Kerrisk <>,
	Willy Tarreau <>, Matthew Garrett <>,
	Ext4 Developers List <>,
	linux-man <>
Subject: Re: [PATCH v3 0/8] Rework random blocking
Date: Fri, 27 Dec 2019 17:08:57 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Dec 27, 2019 at 10:22:23PM +0100, Stephan Mueller wrote:
> I am unsure but it sounds like you are refuting your blocking_pool 
> implementation. Nothing more and nothing less than the blocking_pool, just 
> with a more modern and further analyzed DRNG is what was referenced as a TRNG.

Yes, and that's why I am planning on taking Andy's patches to drop the
blocking pool.  Trying to make the claim that you can read one byte
from /dev/random if and only if one byte of entropy has flowed into
it.... is a mug's game, for the reasons I gave above.

> Or maybe the terminology of TRNG (i.e. "true") is offending. I have no concern 
> to have it replaced with some other terminology. Yet, I was just taking one 
> well-defined term.

But my point is that it *isn't* a well defined term, precisely because
it's completely unclear what application programmer can expect when
they try to use some hypothetical GRANDOM_TRUERANDOM flag.  What does
that *mean*?  The kernel can't offer up any guarantees about whether
or not the noise source has been appropriately characterized.  All
say, a GPG or OpenSSL developer can do is get the vague sense that
TRUERANDOM is "better" and of course, they want the best security, so
of *course* they are going to try to use it.  At which point it will
block, and when some other clever user (maybe a distro release
engineer) puts it into an init script, then systems will stop working
and users will complain to Linus.

And then we'll have companies like Intel claiming that RDSEED has been
very carefully characterized --- by them --- and we should *obviously*
trust it, and wire up RDSEED so that TRUERANDOM will have a near
infinite supply of really good entropy.  And they might even be
correct.  But this way lies a huge mess which is fundamentally social,
not technical.

The claim we can make for getrandom(2) is that we do the best job that
we can, and we feed in as many sources as possible and hope that at
least one or more sources is not known to the attacker.  One of the
sources could very well be AES(NSA_KEY, SEQ++).  But that still will
protect us from the Chinese and Russian crypto teams.  And we can hope
that the NSA doesn't have access to the inter-packet arrival times on
the local area network, or the radio strength as recorded from the
WiFi radio, etc. etc.  But note that we didn't make any claims of how
many bits of entropy that we have; it helps that we are implicitly
making a claim that we trust the crypto algorithms.   

> > So let's take a step back and ask the question: "Exactly what _value_
> > do you want to provide by creating some kind of true random
> > interface?"  What does this enable?  What applications does this
> > really help?
> There are simply cryptographers who have use cases for such random numbers. 
> The core use case is to seed other DRNGs and avoiding the chaining of free-
> running DRNGs.

For this very specialized use case, what I think the kernel should
provide is maximal transparency; that is, given the DRBG direct access
to the TPM's random number generator, or direct access to the
ChaosKey, and the userspace DRBG should be able to get a list of the
various hardware RNG's, and select one, with the characterization
being done userspace, not in the kernel.

The kernel shouldn't be mixing various noise sources together, and it
certainly shouldn't be trying to claim that it knows how many bits of
entropy that it gets when is trying to play some jitter entropy game
on a stupid-simple CPU architecture for IOT/Embedded user cases where
everything is synchronized off of a single master oscillator, and
there is no CPU instruction reordering or register renaming, etc.,

You can talk about providing tools that try to make these estimations
--- but these sorts of things would have to be done on each user's
hardware, and for most distro users, it's just not practical.

So if it's just for cryptographers, then let it all be done in
userspace, and let's not make it easy for GPG, OpenSSL, etc., to all
say, "We want TrueRandom(tm); we won't settle for less".  We can talk
about how do we provide the interfaces so that those cryptographers
can get the information they need so they can get access to the raw
noise sources, separated out and named, and with possibly some way
that the noise source can authenticate itself to the Cryptographer's
userspace library/application.

But all of this should probably not be in drivers/char/random.c, and
we probably need to figure out a better kernel to userspace interface
than what we have with /dev/hwrng.

					- Ted

  reply	other threads:[~2019-12-27 22:10 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23  8:20 [PATCH v3 0/8] Rework random blocking Andy Lutomirski
2019-12-23  8:20 ` [PATCH v3 1/8] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski
2020-01-07 20:42   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 2/8] random: Add a urandom_read_nowait() for random APIs that don't warn Andy Lutomirski
2020-01-07 20:43   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 3/8] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski
2020-01-07 20:44   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 4/8] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski
2020-01-07 20:44   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 5/8] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski
2020-01-07 21:02   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 6/8] random: Remove the blocking pool Andy Lutomirski
2020-01-07 21:03   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 7/8] random: Delete code to pull data into pools Andy Lutomirski
2020-01-07 21:03   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 8/8] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski
2020-01-07 21:04   ` Theodore Y. Ts'o
2019-12-26  9:29 ` [PATCH v3 0/8] Rework random blocking Stephan Müller
2019-12-26 10:03   ` Matthew Garrett
2019-12-26 11:40     ` Stephan Mueller
2019-12-26 11:12   ` Andy Lutomirski
2019-12-26 12:03     ` Stephan Mueller
2019-12-26 12:46       ` Andy Lutomirski
2019-12-27  9:55         ` Stephan Mueller
2019-12-26 14:04       ` Theodore Y. Ts'o
2019-12-26 23:29         ` Andy Lutomirski
2019-12-27 10:29           ` Stephan Mueller
2019-12-27 13:04             ` Theodore Y. Ts'o
2019-12-27 21:22               ` Stephan Mueller
2019-12-27 22:08                 ` Theodore Y. Ts'o [this message]
2019-12-28  2:06                   ` Andy Lutomirski
2019-12-29 14:49                     ` Theodore Y. Ts'o
2019-12-29 15:08                       ` Andy Lutomirski
2019-12-28  7:01                   ` Willy Tarreau
2020-01-09 22:02                   ` Kurt Roeckx
2020-01-09 22:02                     ` Kurt Roeckx
2020-01-09 22:40                     ` Theodore Y. Ts'o
2020-01-09 22:40                       ` Theodore Y. Ts'o
2020-01-09 23:02                       ` Kurt Roeckx
2020-01-09 23:02                         ` Kurt Roeckx
2020-01-10  7:53                         ` Stephan Mueller
2020-01-10  7:53                           ` Stephan Mueller
2020-01-10  0:30                     ` Andy Lutomirski

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.