In response to some people claiming that using a CSPRNG is "going way overboard" and/or is "overkill", I've written this test to verify the performance impact of using a CSPRNG versus their insecure mt_rand()
based hacks.
I think the results are conclusive (at least on my device): A 50% speed increase. In addition to less-predictable randomness.
If anyone would like to suggest a benchmark script (or conditions that lead to different results with mine), let me know and I will link to them here.
Hey @sarciszewski, I only just saw this. I am co-author of the CSPRNG-in-core RFC for PHP 7.
https://github.com/lt/php-src/tree/rand-bytes
On a vanilla Linux install the
random_bytes()
function is comparable in speed to OpenSSL. OpenSSL still has the edge because (by default) it doesn't read directly from the systems sources of random all the time, it maintains it's own random pool and does a bunch of "stuff" for FIPS compliance, so it has an in-memory buffer it can draw on which gives it a bit more speed.On FreeBSD and OpenBSD it absolutely blows OpenSSL out of the water.
Also worth noting, if you install and build against LibreSSL-portable on Linux, you're also going to get much faster speeds than regular OpenSSL due to it providing it's own arc4random functions.
Edit:
Also,
mcrypt_create_iv()
does not depend on the mcrypt library. It's just a wrapper aroundCryptGenRandom
on Windows and/dev/*random
on Linux. A lot of the performance hit is because it opens/closes the file descriptor for every call.Edit 2:
I refuse to sign up to reddit. If you have any questions about how (CS)RNGs function in PHP, or why things are slower/faster, ping me here, come have a chat on SO (http://chat.stackoverflow.com/rooms/11/php), or fire an email to leight -> gmail