Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZw82Vi14ojv2vfxyrfoa-uL54smUSyy-xDZouaHXjRp1g@mail.gmail.com>
References: <CALYT1YrHA=E13eqzKnLSPSATdxRy_201yVDp-cdPurQeSkBhrQ@mail.gmail.com>
	<CAPhkiZw82Vi14ojv2vfxyrfoa-uL54smUSyy-xDZouaHXjRp1g@mail.gmail.com>
Date: Tue, 24 Feb 2015 10:56:33 +0000
Message-ID: <CAPwsocHAqkBquVR1XEYMFZnafL47HkC4eCW4Z9mFin4iCyZC8A@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Sammy Kaye Powers <me@sammyk.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG
From: leight@gmail.com (Leigh)

Hi Andrey,

On 24 February 2015 at 09:51, Andrey Andreev <narf@devilix.net> wrote:
> I noticed that the patch checks for /dev/arandom availability first,
> and I'm pretty sure that on systems that have it, /dev/urandom simply
> redirects to /dev/urandom, so that might be a bit redundant ... Maybe
> Leigh can say more about this if I'm missing something.

You're absolutely right, on modern releases of systems like OpenBSD
and OSX /dev/urandom is simply an alias of /dev/arandom. The problem
is, I'm not an expert in _every_ version of _every_ OS, and it might
not always be the case that this aliasing exists. I'd also like to
think this adds an element of future-proofing. If I wish for it hard
enough, maybe one day Linux in general will introduce /dev/arandom,
but maybe at first /dev/urandom does not alias it until some time
later.

> Also, you don't need 100s of lines of code to write the same thing in
> userland ... you need ~30 lines, your Facebook SDK example is just
> over-complicated. I'm sure everybody will agree that this is a feature
> that PHP needs, so I think you should rather focus on explaining that
> it's better than leaving it to userland implementations that may screw
> up a lot of details.

I agree, we can make a succinct explanation that focuses on the
importance of "getting it right".

> And finally, a suggestion to remove the default $length value of 16
> for random_bytes() - it just happens to be what you need for i.e. an
> AES-128 IV, but other than that it doesn't make sense to have a
> default length.

This is just a badly formatted part of the RFC. There is no default
for random_bytes().

The defaults for random_int() are however +/- PHP_INT_MAX

> Otherwise - great! I'm really looking forward to this, and many others
> surely do as well. I've got no doubt that the RFC will pass and I
> intend to write a compat package for use in pre-PHP7 environments, to
> ease the new API's adoption.

Thanks :)