Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55055F1D.2020200@beccati.com>
References: <CALYT1YrJrGAnjVFNQ5HHpYJmFnS4W9PH7XFU557Q=aHH0Jrb2A@mail.gmail.com>
	<55055F1D.2020200@beccati.com>
Date: Sun, 15 Mar 2015 20:09:36 +0000
Message-ID: <CAPwsocGp7rn6piD63SoJcx_vU_-TpCjpFC7C4GP7fWQHQmSsnw@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Sammy Kaye Powers <me@sammyk.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30334b77140f4005115950ca
Subject: Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
From: leight@gmail.com (Leigh)

--20cf30334b77140f4005115950ca
Content-Type: text/plain; charset=UTF-8

On 15 March 2015 at 10:29, Matteo Beccati <php@beccati.com> wrote:
>
> I want to vote yes, but naming is something that scares me a bit. Without
> any indication that it's CSPRNG, people might start using it even when
> unnecessary, and I'd be worried about potential negative effects, such as
> exhausting the entropy pool. It's probably more of a documentation problem,
> but we know many won't read the docs and a "hint" in the function name
> could help guiding users.
>

I wouldn't worry about exhausting the entropy pool, on systems like Linux
there is kind of a feedback system where data is mixed back into the pool
when you request data. You can pipe /dev/urandom into /dev/null for hours
and not suffer any problems.


> For example, it would be overkill to use random_int() to randomly pick the
> content of a boxes at each reload of a web page, but if what I need is a
> *random int*, then random_int() seems a far better choice than some obscure
> rand() or mt_rand().
>

Of course it would, but that's something that needs to be done through
education and via the manual. I understand the concern, but I'm not sure
how much I'll worry about it.

Or in the poker deck example, wouldn't it be enough just to seed mt_srand
> with a crypto-secure number to remove the biasing and using mt_rand to
> shuffle the deck?
>

The biasing comes from how the result is restricted to a certain range of
numbers, it's not related to the quality of the seed. We avoid that by
throwing away numbers that would give a biased result, and picking a new
number.

The poker deck example isn't a brilliant one, because the effects of
biasing become more apparent the closer you get to the maximum upper bound,
but it's still important to cater for the unlikely-but-possible scenarios.

--20cf30334b77140f4005115950ca--