Random Number Generator Recommendations for Applications(peteroupc.github.io) |
Random Number Generator Recommendations for Applications(peteroupc.github.io) |
One thing to keep in mind: there’s been a bit of a feud in the PRNG space between the Vigna camp [1] with xoroshiro and newcomer O’Neill [2] with PCG.
This website seems stay on the traditional side and shy away from recommending PCG. I’m not really qualified to judge on that dispute [3], but I think both options are better, smaller, faster than the good old Mersenne Twister, so it’s time that we moved on from that [4] and pick one of the latest generation PRNGs.
FWIW, Julia now uses xoshiro256++ by default [5], and they investigated their choice quite thoroughly, I believe.
[2] https://www.pcg-random.org/
[3] https://pcg.di.unimi.it/pcg.php
And the reply https://www.pcg-random.org/posts/on-vignas-pcg-critique.html
The timestamp was down to a fraction of a second, so instead of having 52! possible decks (about 2^226) there were only 2^32 possible decks that could be generated by the algorithm.
Also for an example of exploiting a gambling site that used javascript's Math.random https://jonasnick.github.io/blog/2015/07/08/exploiting-csgoj...
It also suggests os.urandom as a Python RNG which (as the name suggests) uses /dev/urandom or the getrandom() syscall, both of which are PRNGs
There aren't a lot of cases where you need to explicitly reach for a non-PRNG over a PRNG, and if you do need it, you most likely know it. What does often make a lot of sense is using a PRNG that is seeded from a non-PRNG.
> It also suggests os.urandom as a Python RNG which (as the name suggests) uses /dev/urandom or the getrandom() syscall, both of which are PRNGs
So, that's not ENTIRELY accurate. At least on Linux, while /dev/urandom uses a PRNG, but it is fed from the entropy pool. So unless you consume the entropy pool of a system, it has all the randomness of /dev/random. The difference is that /dev/random blocks when you run out of entropy, while /dev/urandom will just keep feeding output generated purely from the PRNG until more entropy becomes available.
There are some notable exceptions, but in most cases pulling from /dev/urandom is the right choice.
See Jason Donenfeld's authoritative talk on the Linux RNG for details: https://youtu.be/-_yzaSp2xtY
TL;DR he article has glaring inconsistencies and shouldn’t be regarded reliable
In this case, their speed, repeatability and “good enough” statistical properties haven’t motivated much to change.
Although there are alternatives like using low discrepancy sequences (Halton, Sobol) which don't explicitly need the random number values generated from a PRNG itself which are used as well...
https://www.php.net/manual/en/function.random-bytes.php
Edit: the PHP docs seem to meet the requirements from the article but, the article has a different recommendation (odd?, Maybe I missed something)
edit: now after reading about rand_xoshiro i'm curious to try it out
https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa...
The "wait_for_random_bytes" function is still there: https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa...
Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state.
> I don't think this "PRNG" vs. "RNG" distinction is doing us much good.
But it's still nice to seed and periodically reseed a PRNG w/ entropy from an RNG. So there is a distinction between PRNG and RNG to be made, and we should make it. What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.
Yes, of course. PRNG's are about producing random data from a seed. But /dev/random & /dev/urandom isn't just a PRNG.
> What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.
Which is effectively what is going on with /dev/random & /dev/urandom
That said: today you'd just use some variant of getrandom.
Isn't that more a function of hardware than software? The hardware random number generators on modern CPUs pretty much eliminate the need to worry about entropy...