# Default mcrypt_create_iv() to /dev/urandom - Thread: https://externals.io/message/72993 - Original archive: https://news-web.php.net/php.internals/72993 - Started by Nikita Popov on 2014-03-07T15:56:42+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #72993 — Nikita Popov — 2014-03-07T15:56:42+00:00 URL: https://externals.io/message/72993#72993 Hi internals! Currently the mcrypt_create_iv() function uses /dev/random as the default source for random bytes. This is problematic, because /dev/random will block if entropy for reseeding the kernel's CSPRNG is estimated to be low. If mcrypt_create_iv() with default parameters is used in any kind of user-facing code the blocking will cause unpredictable slowdowns and can be easily exploited for a denial of service attack. /dev/urandom - contrary to popular misconception - is also a cryptographically safe source of randomness and is recommended over the use of /dev/random for most (sometimes all) applications [1] [2] [3] [4] [5]. Quoting from the /dev/random man page [1]: > If you are unsure about whether you should use */dev/random* or > */dev/urandom*, then probably you want to use the latter. As a > general rule, */dev/urandom* should be used for everything except > long-lived GPG/SSL/SSH keys. [*] One potential issue when using /dev/urandom is that on some systems (notably Linux, but not BSD) it will not block even if it can't gather enough initial entropy for seeding the CSPRNG and as such produce predicable outputs. This condition can only occur immediately after system startup and as per the /dev/random man page [1] this is mitigated by "all major Linux distributions [...] since 2000 at least" by saving a seed file. As such I would suggest defaulting the mcrypt_create_iv() $source parameter to MCRYPT_DEV_URANDOM. Objections? Nikita [*] The latter claim is disputed, see for example the end of [4]. [1]: http://man7.org/linux/man-pages/man4/random.4.html [2]: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ [3]: http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939 [4]: http://blog.cr.yp.to/20140205-entropy.html [5]: http://www.2uo.de/myths-about-urandom/ --- ## #72996 — Pierre Joye — 2014-03-07T17:18:53+00:00 URL: https://externals.io/message/72993#72996 · In reply to: #72993 Hi Nikita, > > Hi internals! > > Currently the mcrypt_create_iv() function uses /dev/random as the default > source for random bytes. This is problematic, because /dev/random will > block if entropy for reseeding the kernel's CSPRNG is estimated to be low. > If mcrypt_create_iv() with default parameters is used in any kind of > user-facing code the blocking will cause unpredictable slowdowns and can be > easily exploited for a denial of service attack. > > /dev/urandom - contrary to popular misconception - is also a > cryptographically safe source of randomness and is recommended over the use It is not, see below. > of /dev/random for most (sometimes all) applications [1] [2] [3] [4] [5]. > Quoting from the /dev/random man page [1]: > > > […] And that is exactly why it fits on cryptographic safe. See the other discussions about prng, there is a lot of confusion about this wording. :) > One potential issue when using /dev/urandom is that on some systems > (notably Linux, but not BSD) it will not block even if it can't gather > enough initial entropy for seeding the CSPRNG and as such produce > predicable outputs. This condition can only occur immediately after system > startup and as per the /dev/random man page [1] this is mitigated by "all > major Linux distributions [...] since 2000 at least" by saving a seed file. > > As such I would suggest defaulting the mcrypt_create_iv() $source parameter > to MCRYPT_DEV_URANDOM. Objections? I have no objection as uramdom is good enough for 99.999% of php usage. Cheers, Pierre > Nikita > > [*] The latter claim is disputed, see for example the end of [4]. > > [1]: http://man7.org/linux/man-pages/man4/random.4.html > [2]: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ > [3]: > http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939 > [4]: http://blog.cr.yp.to/20140205-entropy.html > [5]: http://www.2uo.de/myths-about-urandom/ --- ## #72997 — Yasuo Ohgaki — 2014-03-08T00:18:56+00:00 URL: https://externals.io/message/72993#72997 · In reply to: #72996 HI all, > > […] > system > > […] > file. > > […] > parameter > > […] > > I have no objection as uramdom is good enough for 99.999% of php usage. I have no objection neither. Pierre has proposed unified RNG/PRNG source setting. I would like to see this in 5.6 and make php.ini's PRNG the default. Mess would be growing without unified RNG/PRNG. If there is unified PRNG setting in INI, I'll take care session module to use it just like encoding settings. i.e. Specific setting has more precedence than general setting. Regards, P.S. Thank you for taking care of this, Nikita. -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #73002 — Pierre Joye — 2014-03-08T07:01:02+00:00 URL: https://externals.io/message/72993#73002 · In reply to: #72997 > HI all, > > > > […] By the way, a very good read: http://www.2uo.de/myths-about-urandom/ pretty much covers what we have been discussing here lately :) and PHP fits in the "most of use cases" part of this post. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #73006 — Derick Rethans — 2014-03-08T20:39:17+00:00 URL: https://externals.io/message/72993#73006 · In reply to: #72993 > As such I would suggest defaulting the mcrypt_create_iv() $source > parameter to MCRYPT_DEV_URANDOM. Objections? No, flip it. This probably has changed in the last 10 years, since I wrote that code :-) cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine