Date:	Tue, 21 Jun 2016 14:22:48 -0400
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Stephan Mueller <smueller@...onox.de>
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

On 2016-06-21 12:28, Stephan Mueller wrote:
> 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.
I'm not commenting about them wanting cryptographically secure entropy. 
My statement about the intelligence of the people who wrote the standard 
was commenting on their saying '/dev/random shall be used' instead of 'a 
cryptographically secure entropy source shall be used'.  POSIX requires 
that the first statement imply the second, but the second does not 
require the first.  Their choice to use the first indicates that they 
assume this will be the only implementation that will ever matter, and 
that POSIX systems will be the only thing anyone using the standard 
cares about, both of which are inherently poor assumptions outside of a 
completely closed system.  Most standards proposed or mandated by 
bureaucracies have similar issues making bad assumptions about the 
context in which they will be used.

> 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.
The fact that that's how /dev/urandom works is a result of the 
implementation, I already listed at least 3 UNIX derivatives that do not 
work this way and provide cryptographically secure entropy from the same 
source stream for both /dev/random and /dev/urandom.  Changing this on 
Linux would not break backwards compatibility as long as we provide 
sufficient entropy via /dev/random, because nobody depends on it 
blocking for anything other than ensuring they get good entropy, so if 
it always returns good cryptographically secure entropy, we never need 
to block unless the generator hasn't yet been seeded.  Now, on top of 
that, there's still no absolute guarantee that what you get from 
/dev/random is actually cryptographically secure, but that's a separate 
issue.

Powered by blists - more mailing lists