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.
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: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. [*]
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.
[3]:
HI all,
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.
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
HI all,
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.
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
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