Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-zPTTdYp7pngUhE+8Tgt=c5KwaevRMepHo_GEE5k2Bug@mail.gmail.com>
References: <CAF+90c-zPTTdYp7pngUhE+8Tgt=c5KwaevRMepHo_GEE5k2Bug@mail.gmail.com>
Date: Fri, 7 Mar 2014 18:18:53 +0100
Message-ID: <CAEZPtU5Q153ku0dRrXvn7ysm-rF5O791pMxewdEnhSMg_+KGxg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c12bf0b9b05a04f40772cf
Subject: Re: [PHP-DEV] Default mcrypt_create_iv() to /dev/urandom
From: pierre.php@gmail.com (Pierre Joye)

--001a11c12bf0b9b05a04f40772cf
Content-Type: text/plain; charset=UTF-8

Hi Nikita,
On Mar 7, 2014 4:56 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote:
>
> 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].
>
>  [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/

--001a11c12bf0b9b05a04f40772cf--