And that's another reason why it's a good thing that PHP 7 (coming out soon!) has a new function called random_int() which provides an unbiased distribution of integers powered by a CSPRNG (yes, it uses urandom, in case anyone asks).
My employer is leading the effort to expose a compatible interface in PHP 5 applications so developers can add one line to their composer.json file and start writing code for PHP 7. It's MIT licensed and should nearing its 1.0.0 release soon.
Using /dev/urandom is not a good thing.
It's only needed to get secure random numbers (CSPRGs) very slowly. You'll drain it so that the apps which really need it will be out of seeds.
To get random numbers fast, you need to use the good bits of a PRG based on an LCG.
Everybody should know by now that the mersenne twister is not only bad, but also slow.
Everybody should know by now that the first bits are good, and the last bits horrible. That's why you should not use modulo %, but rshift or better use Melissa E. O'Neill's PCG, which uses the first good bits to improve the latter worse bits.
http://www.pcg-random.org/
There is in practical terms no such thing as "draining a secure random number generator".
Most RNGs are at bottom stream ciphers. The stream cipher problem of stretching a small key into a very large keystream is fundamental to cryptography, and RNGs are an instance of that problem in the most favorable setting: no message boundaries and no coordinated state.
You don't in practice worry about AES-CTR "running out of key", and so you shouldn't worry about urandom "running out of entropy".
It's understandable why so many people believe this: the Linux urandom man page invents a whole parallel universe in which this is not only a live issue, but one with applications to specific kinds of cryptography! Until we find the appropriate incantations to shut down that particular portal to the world of the Elder Things, it's best just not to look at it.
It sounds kinda analog to a one-time-pad vs. ordinary key encryption. Waiting for more "actual" entropy bits rather than stretching the existing entropy is like a one time pad, and it can (with a bit of effort, and assuming the integrity of the sources) guarantee similar security of the random generator to a one time pad.
Stretching of the key means (at least in theory) that you could break the random function and predict the random series or your position in it.
I guess your point of not worrying about ordinary key encryption should be applicable in an RNG context too and be similarly safe, though.
mt_rand() performs worse than CSPRNGs, funny enough
Using a strong PRF we can take a 128-bit seed and turn it into an endless stream of random numbers. If /dev/urandom drains entropy, that's a bug that your OS should fix.
> Everybody should know by now that the first bits are good, and the last bits horrible. That's why you should not use modulo %, but rshift or better use Melissa E. O'Neill's PCG, which uses the first good bits to improve the latter worse bits. http://www.pcg-random.org/
Yeah, there is no pgc_random() function in PHP though.
> mt_rand() performs worse than CSPRNGs, funny enough
Because the Mersenne twister is outdated technology, which
is bad and slow. Use pcg instead.
> If /dev/urandom drains entropy, that's a bug that your OS should fix.
Defying logic? Without a HW source for noise that's impossible. Even if people are arguing being practical to drop security, you should not be convinced.
I didn't see tests which would confirm this theory.
> Yeah, there is no pgc_random() function in PHP though
Writing that binding would cost a php-c dev 20 minutes. But they should not.
The problem is the bike shedding to replace that in the stdlib for rand(). Better, faster? But...
My employer is leading the effort to expose a compatible interface in PHP 5 applications so developers can add one line to their composer.json file and start writing code for PHP 7. It's MIT licensed and should nearing its 1.0.0 release soon.
https://github.com/paragonie/random_compat