linux-kernel - Re: [PATCH v5 0/7] /dev/random

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: <183335903.ioesrD1Ugf@tauon.atsec.com>
Date:	Tue, 21 Jun 2016 18:28:40 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
Cc:	Nikos Mavrogiannopoulos <nmav@...tls.org>,
	Theodore Ts'o <tytso@....edu>, Pavel Machek <pavel@....cz>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Andi Kleen <andi@...stfloor.org>,
	Sandy Harris <sandyinchina@...il.com>,
	Jason Cooper <cryptography@...edaemon.net>,
	John Denker <jsd@...n.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Joe Perches <joe@...ches.com>,
	George Spelvin <linux@...izon.com>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:

Hi Austin,

> On 2016-06-21 03:32, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
> > 
> > Hi Nikos,
> > 
> >> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller <smueller@...onox.de>
> > 
> > wrote:
> >>>> Personally, I don't really use /dev/random, nor would I recommend it
> >>>> for most application programmers.  At this point, getrandom(2) really
> >>>> is the preferred interface unless you have some very specialized
> >>>> needs.
> >>> 
> >>> I fully agree. But there are use cases for /dev/random, notably as a
> >>> seed
> >>> source for other DRNG.
> >> 
> >> Is that really the case? I believe all DRNG's use /dev/urandom anyway
> >> for seeding since they cannot afford indeterminate blocking. It would
> >> be a gain for everyone if /dev/random was the same as /dev/urandom in
> >> Linux.
> > 
> > For standard approaches, this is true. But there are regulations, notably
> > in the German realm, /dev/random shall be used, at least partially (see
> > AIS 20/31).
> 
> Which just goes to show how utterly stupid some people who write laws
> and regulations are.  Saying specifically that '/dev/random shall be
> used' does not enforce any improvement of entrophic value in the data at
> all, it just coincidentally improves the theoretical quality of the data
> because of how Linux and some legacy UNIX systems are designed.  This
> 'regulation' already provides zero benefit other than a placebo effect
> on at least OpenBSD, FreeBSD, and I'm pretty certain most other BSD
> derivatives, as /dev/random and /dev/urandom point to the same thing
> there (on OpenBSD it's an arcfour based drbg, FreeBSD does similar but
> uses a CSPRNG called Fortuna), and while I'm not certain, I believe AIX
> does likewise (although they use a design based on yarrow).

It is NOT utterly stupid, you should listen to the reasons. The core reason is 
explained with the following analogy:

/dev/urandom, for a short period of time, operates as a DRNG. For the sake of 
discussion, let us assume that it is a DRNG which is, for the sake of 
discussion, seeded with 256 bits of entropy.

Now, you pull 256 bits out of it, you have 256 bits of entropy.

You pull again 256 bit out of it -- what entropy do you have? You do NOT have 
*again* 256 bits of entropy. All you can say is the entire generated 512 bits 
have collectively 256 bits of entropy. And so on and so forth.

Now, if you want to say that your newly spawned DRNG is seeded with X amount 
of entropy, the DRNG nature of /dev/urandom makes such a statement a 
challenge. The easy way out of the challenge is to use /dev/random (I am aware 
of the fact that the DRNG has a computational strength, but it is not, well, 
entropy).

In addition, when using /dev/urandom, you have to show that at the time you 
seed the DRNG, it is fully seeded. That is a challenge at boot time - a 
challenge this entire thread revolves around. Yes, getrandom(2) is the way 
out, but not everybody uses it. Again, /dev/random does NOT have this 
challenge.
> 
> On top of that though, just because some poorly thought out standard
> requires it's usage doesn't mean we have to work based on that.

I cannot concur.


Ciao
Stephan