Bug 71211

For reference, I paste here an email discussion of this bug from 2015:




-------- Forwarded Message --------
Subject: Re: Status for bug 71211? [random(4): clarify utility and volume]
Date: Mon, 27 Jul 2015 18:34:52 +0200
From: Laurent Georget <laurent@lgeorget.eu>
To: Carl Winbäck <c@tunnel53.net>, mtk.manpages@gmail.com
CC: linux-man@vger.kernel.org


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

the text of this man page has been the subject of endless controversies
for ages. CSPRNGs are confusing and the page unfortunately adds a
little to the confusion. The newer getrandom(2) page is better, and I
(personally, this doesn't engage Michael nor any other author) think
that the random(4) page should be rewritten in the same spirit.
(getrandom is a system call used to get a random number, by default,
it's more or less equivalent than reading from /dev/urandom if you call
it without flags and for less than 256 bytes).

Compare this in random(4)

> The kernel random-number generator is designed to produce a small
> amount of high-quality seed material to seed a cryptographic pseudo-
> random number generator (CPRNG). It is designed for security, not
> speed, and is poorly suited to generating large amounts of random
> data. Users should be very economical in the amount of seed material
> that they read from /dev/urandom (and /dev/random); unnecessarily
> reading large quantities of data from this device will have a
> negative impact on other users of the device.
with this in getrandom(2)

> *getrandom*() relies on entropy gathered from device drivers and other
> sources of environmental noise.  Unnecessarily reading large
> quantities of data will have a negative impact on other users of the
> //dev/random/ and //dev/urandom/ devices.  Therefore, *getrandom*() should
> not be used for Monte Carlo simulations or other programs/algorithms
> which are doing probabilistic sampling.
This says exactly the same thing, but getrandom(2) is less misleading.
First note that the man page for random says that /dev/urandom is
"poorly suited to generating large amounts of random data", not
"poorly suited to generating large amounts of *cryptographic* random data".
Basically, you can use /dev/urandom for all cryptographic purposes,
because you never need so many bits at once when doing cryptography.
Even generating several 16-bytes (128-bits) UIDs per minute if you need
them to be cryptographically secure (you may want to think about this
requirement, is it strict?) is not that much. A Monte-Carlo simulation
requires, say (I don't know exactly let's make a rough guess) around
several MB of random numbers per minute. That's 4 or 5 orders of
magnitude higher than your UIDs use case. This would be a wrong
usage of /dev/urandom for two reasons:
- - it would be awfully slow
- - you don't need cryptographically secure random numbers, so there's
no need to deplete the entropy pool.
Next, compare this in random(4):

> If  you    are  unsure  about  whether  you  should  use  /dev/random  or
> /dev/urandom,  then  probably you want to use the latter.  As a general
> rule, /dev/urandom should be  used  for    everything  except  long-lived
> GPG/SSL/SSH keys.
with this in getrandom(2):

> Unless  you  are     doing    long-term key generation (and perhaps not even
> then), you probably shouldn't be using GRND_RANDOM.  The     cryptographic
> algorithms  used for /dev/urandom are quite conservative, and so should
> be sufficient for all purposes.    The  disadvantage  of  GRND_RANDOM  is
> that  it     can block.  Furthermore, dealing with the partially fulfilled
> getrandom() requests that can occur when     using    GRND_RANDOM  increases
> code complexity.
Again, the two man pages say the same. getrandom(2) is more nuanced,
though.

To answer your question about how much you can ask /dev/urandom for :

in random(4) :

> if any program reads more than 256 bits (32 bytes) from the kernel    random
> pool  per  invocation, or per reasonable reseed interval (not less than
> one minute), that should be taken as a sign that its  cryptography  is
> not skillfully implemented.
In getrandom(2):

> Calling getrandom() to read /dev/urandom for small values  (<= 256 bytes)
> of buflen is the preferred mode of usage.
Furthermore, it's impossible to read more than 32MB from /dev/urandom
per invocation.

So, actually, the random(4) page is very conservative about the reading
limit.

My final conclusion: as long as you use /dev/urandom for cryptographic
purposes only, you should be ok, because you will never need *a lot* of
random data anyway in any sensible program. For non-cryptographic usage,
seed a user-space PRNG with a few bytes from /dev/urandom and you will
be good.

Laurent



Le 26/07/2015 22:20, Carl Winbäck a écrit :
> Hello Michael & Co,
>
> I would like to bring your attention to bug report 71211, ”random(4):
> clarify utility and volume”.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=71211
>
> This report was filed over a year ago but still hasn’t received any response.
>
> Michael, do you have the time to take a look?
>
> Perhaps you, or someone else on the linux-man list, are familiar with
> CSPRNGs and have some ideas on how to reword this man page?
>
> Unfortunately I’m not at all an expert in this area, so I’m afraid I
> don’t have any specific suggestions regarding how to change this man
> page. But I still think it would be helpful to the Linux community if
> it could be improved, and as a result, hopefully cause less confusion
> regarding getting random numbers on Linux.
>
>
> Looking forward to hear your thoughts on this.
>
> Best regards,
> Carl Winbäck
> --
> To unsubscribe from this list: send the line "unsubscribe linux-man" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlW2XawACgkQRTidSplJch4jJQD/d4LOrShlXmQx5RClVCdj7sKL
6n7SQhlCIjfqvi86JDcA/28cCtYZ8HKL1RgWkgEjGmWoIH6ZA+AKJjgnmugk1wFj
=ff9U
-----END PGP SIGNATURE-----

Substantial updates have been to the latest release (4.09) of man-pages that, I believe, address the problems in this bug. See the revise random(4) page and the new random(7) page.

http://man7.org/linux/man-pages/man4/random.4.html
http://man7.org/linux/man-pages/man7/random.7.html

I'm closing this bug. If you think there's still some unresolved issue, please reopen (wand add some detail on what problems you still see).