7 ms·

> Using /dev/urandom is not a good thing. It's only needed to get secure random numbers (CSPRGs) very slowly. https://gist.github.com/sarciszewski/f7bd4c0358a4

> Using /dev/urandom is not a good thing. It's only needed to get secure random numbers (CSPRGs) very slowly. https://gist.github.com/sarciszewski/f7bd4c0358a44321787b https://gist.github.com/sarciszewski/f7bd4c0358a44321787b http://3v4l.org/j330O http://3v4l.org/j330O 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/ http://www.pcg-random.org/ Yeah, there is no pgc_random() function in PHP though.

rurban 11y ago
> 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...
- sarciszewski 11y ago
  > Writing that binding would cost a php-c dev 20 minutes. Most PHP devs are not C devs.