A system call for random numbers: getrandom()

Posted Jul 26, 2014 2:23 UTC (Sat) by idupree (guest, #71169)
Parent article: A system call for random numbers: getrandom()

Does getrandom(buf, 0, flags) block/EAGAIN if the requested kind of entropy is unavailable? Or does it succeed? If the former, getrandom(buf, 0, GRND_NONBLOCK) could be a way to find out if the urandom pool is uninitialized.

Why "It should not be used for Monte Carlo simulations or other programs/algorithms which are doing probabilistic sampling." (in the patch's man page): I'd like to see the man page say why. According to http://thread.gmane.org/gmane.linux.kernel.cryptoapi/11666 the reason is: "It will be slow, and then the graduate student will whine and complain and send a bug report. It will cause urandom to pull more heavily on entropy, and if that means that you are using some kind of hardware random generator on a laptop, such as tpm-rng, you will burn more battery, but no, it will not break. This is why the man page says SHOULD not, and not MUST not. :-)"

to post comments

A system call for random numbers: getrandom()

Posted Jul 31, 2014 5:29 UTC (Thu) by lordsutch (guest, #53) [Link] (3 responses)

Well, if you're doing Monte Carlo or some other statistical analysis, usually you want the ability to replicate the analysis with a chosen seed and get the same numbers out (as well as being able to change the seed and see if you get the same results). The kernel random facility doesn't give you the ability to do that; indeed it's designed to make it very, very hard to get the RNG in the exact same state twice.

A system call for random numbers: getrandom()

Posted Jul 31, 2014 7:41 UTC (Thu) by eternaleye (guest, #67051) [Link] (2 responses)

There's also that the kernel's random number generator is intended to be cryptographic randomness; this is considerably more stringent (and slower, and more computationally expensive) than the statistical randomness needed for Monte Carlo &co. So it's just plain less useful than alternatives like WELL[1] or xorshift+[2]

In addition, it depletes the scarce entropy resources of the kernel by the truckload, which may cause things that _really_ need good cryptographic randomness (long-term public keys, etc) to block indefinitely on /dev/random (since while urandom doesn't block, it _depletes the same pool_ causing random to block).

[1] https://en.wikipedia.org/wiki/Well_Equidistributed_Long-p...
[2] https://en.wikipedia.org/wiki/Xorshift

A system call for random numbers: getrandom()

Posted Jul 31, 2014 16:13 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I'm not sure that /dev/random has "better" or more "real" random numbers than /dev/urandom, when /dev/urandom is fully seeded and initialized it is as good as anything out there. Maybe the only real use case for /dev/random is seeding your own PRNG in userspace, if you are just consuming randomness for cryptographic purposes then /dev/urandom is what you want.

A system call for random numbers: getrandom()

Posted Feb 11, 2016 8:59 UTC (Thu) by akostadinov (guest, #48510) [Link]

Other users of urandom should not cause urandom to become less secure. As some comments pointed out, other users or urandom may even increase urandom entropy (by making it's internal state less predictable).

A good read why `random` is not good idea http://www.2uo.de/myths-about-urandom/