All of
 help / color / mirror / Atom feed
From: Stephan Mueller <>
To: "Theodore Y. Ts'o" <>
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 22:22:23 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am Freitag, 27. Dezember 2019, 14:04:36 CET schrieb Theodore Y. Ts'o:

Hi Theodore,

> On Fri, Dec 27, 2019 at 11:29:22AM +0100, Stephan Mueller wrote:
> > My definition of TRNG is identical to the German AIS 31 and I guess
> > identical to your definition of a TRNG.
> > 
> > A TRNG will produce an amount of random data that is equal to the amount
> > of
> > "fresh" entropy that was provided by the noise source. I.e. it should be
> > identical to the blocking_pool behavior.
> This begs the question of determining: (a) how much "fresh entropy"
> you can actually get from a noise source, (b) at what rate the "fresh
> entropy" is arriving, and (c) what assurance(s) you have that the
> noise source is actually working correctly.
> You can't make those assurances from software alone; it needs to be an
> aspect of holistic design of the hardware's design; the supply chain,
> and the software.  So if we are going to claime that we have something
> like GRND_TRUERANDOM or /dev/trandom, or whatever, it needs to work on
> IOT devices running ARM, RISC-V, MIPS, PowerPC, x86.  Some of these
> architectures have no instruction reordering and are stupid simple;
> some of these hardware platforms may have no high-resolution clock or
> cryptographic instructions.
> In addition, if you use a hardware device which is USB attached, how
> does the kernel know that it really is the device that you think it
> is?  The only way you know that a ChaosKey is a ChaosKey is by its USB
> vendor and product id --- which can be easily forged by an attacker,
> either in the supply chain or delivery path, or who walks up to the
> laptop, yanks out the ChaosKey and replaces it with a "PutinKey" or a
> "NSAKey".
> So creating somethinig which shows up as "true random number
> generator" as a generic Linux concept seems to me to be fraught
> endeavor, and I'm not at all convince people need it.

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.

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.

Yet, I fully agree that a noise source always must be vetted. This is what I 
tried with random.c in [1], specifically section 6.1 for x86 systems.

For my LRNG, I tried that in [2] section 3.2 compliant to SP800-90B. In order 
to provide a means to everybody to perform such entropy analysis, the entire 
tool set required for it is provided:

- with CONFIG_LRNG_TESTING providing an interface to the raw unconditioned 

- with [3] providing a tool set to gather all data needed for an SP800-90B 
compliant quantitative analysis

Unfortunately due to license restrictions, I cannot make the same tool set 
available used for the quantiative study provided with [1] section 6.1.

Finally, to support the conclusions drawn from a noise source analysis, the 
health tests provided with LRNG compliant to SP800-90B are available with 
CONFIG_LRNG_HEALTH_TESTS. These tests help in identifying weak or broken noise 

It is fully clear that such studies of non-physical noise sources do not have 
a stochastical model which implies that we cannot make global statements. That 
is the limitation when using such noise sources. Though, the implementation 
should have sufficient "leeway" (i.e. underestmation) when crediting entropy 
to some events.
> > - add a new GRND_TRUERANDOM flag to getrandom(2) which allows access to
> > the
> > TRNG. Andy did not like it because he mentioned that it may be misused
> > since the syscall is unprivileged.
> Even if we could solve the "how the hell can the kernel guarantee that
> the noise source is legitimate" problem in a general way that works
> across all of the architectures, we still have the problem that
> everyone thinks they need "the good stuff".
> Suppose the system call was privileged and "true randomness" could
> only be accessed as root.  What would happen?  Application programmers
> would give instructions requiring that their application be installed
> as root to be more secure, "because that way you can get access the
> _really_ good random numbers".

That is why I think that it is no bug when this interface can DoS other users 
wanting to access the very same resource. This is the price to pay for getting 
access to this type of data.
> 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.

This is a common approach that you can see in action with the RDSEED 
instruction, for example.
> As I thought while watching the latest Star Wars movie: Why?  Why?
> Whywhywhy?
> 					- Ted





  reply	other threads:[~2019-12-27 21:23 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 [this message]
2019-12-27 22:08                 ` Theodore Y. Ts'o
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.