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 <smuel...@chronox.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.