Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83709
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocHai8brjoCYRY4Dx8XGCUdDbJwaBNQ_61DcGzSjNqiB9Q@mail.gmail.com>
References: <CALYT1YrHA=E13eqzKnLSPSATdxRy_201yVDp-cdPurQeSkBhrQ@mail.gmail.com>
	<CAEZPtU6ZZ1MuoRvZooBgRmxQQ4p5jGFmUoVURwLfgVWhTqpkUg@mail.gmail.com>
	<CAPwsocH6HHVFYAycO-ZFnTKJzW1J8nuRS-x115ttY=wP0eukAg@mail.gmail.com>
	<CAEZPtU5EQO07tPSazwHbpqF38PdUMNyZhAQoiZ+ejvhnFDcKsg@mail.gmail.com>
	<CAAyV7nHE_Y-H-m5sgZTM=q-MKDXg0ycitTN+--0bPBQcSd8T2g@mail.gmail.com>
	<CAEZPtU4HxYs-iRJFGhucf7UzbUBZ3VZ1gjxgVBCJjURwUD-oUQ@mail.gmail.com>
	<CAPwsocHai8brjoCYRY4Dx8XGCUdDbJwaBNQ_61DcGzSjNqiB9Q@mail.gmail.com>
Date: Tue, 24 Feb 2015 14:34:06 -0800
Message-ID: <CAEZPtU5HA6TwOe2nG8wQPto4eo2WhnQLtVBF9J2mTRRbmeG0Zg@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 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: pierre.php@gmail.com (Pierre Joye)

On Tue, Feb 24, 2015 at 1:39 PM, Leigh <leight@gmail.com> wrote:
> On 24 February 2015 at 20:54, Pierre Joye <pierre.php@gmail.com> wrote:
>> On Feb 24, 2015 12:04 PM, "Anthony Ferrara" <ircmaxell@gmail.com> wrote:
>>> PERHAPS, it could be written in such a way that a PECL extension can
>>> alter the RNG to accommodate that usecase. But I'd be wary of that and
>>> core supporting userland RNGs.
>>
>> Yes, driver based. That brings some risk but worth exploring this
>> possibility.
>
> We can make the function a pointer. That's not a problem. The problem
> is when people assign their own function to this pointer :)
>
>> You actually reduce the data set, bytes level or higher, the randomness of
>> the data is then restricted or limited and sequences may happen, worst case
>> it could make it less hard (or easier) to predict. I have seen these cases
>> in a couple of projects which rely heavily on entropy.
>
> If you need very high quality and high throughput entropy I can add
> that to this patch. I left it out for now, because I didn't want this
> to become over-complicated. If not having an fd-less crypto-quality
> high throughput is a show stopper for you then let me know, we can fix
> this.

It is only about the amount of data. The trend to have bunch amount of
apps running on the same physical host, it can exhaust the entropy
quickly.