Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84824
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.50 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 13:17:01 +0000
Message-ID: <CALwr1GnGVHKR8JCbgHqDxmb8e4jrqVA2C3gHLXeAMsURNdOWxg@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Sammy Kaye Powers <me@sammyk.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi Matteo,

On 15 March 2015 at 10:29, Matteo Beccati <php@beccati.com> wrote:
> Disclaimer: I do know a little about security, but I am not a crypto-expe=
rt
> by any means. If I'm saying something silly, just let me know ;)
>
> 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 proble=
m,
> but we know many won't read the docs and a "hint" in the function name co=
uld
> help guiding users.

Were folk to use random_int() by default, it would be actually be
considerably better than the situation today where many reach for
mt_rand() without really considering the use case. Using a strong
source of ints instead of a weak source still ends up with you getting
the requested ints. There's no downside unless the source is blocking.
Using the weak source over a strong source will also get you ints, but
without knowing the use, it has the immediate downside risk of being
from a weak source which shouldn't be used for anything requiring
strong randomness.

So random_int() really is the best first default option to go for when
in doubt, with some careful consideration before switching to
mt_rand().

As for exhausting the entropy pool, this is something of a
misconception. The sources in the RFC are pseudorandom generators
which won't exhaust the entropy pool by design.

> For example, it would be overkill to use random_int() to randomly pick th=
e
> 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 obscu=
re
> rand() or mt_rand().
>
> 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?

In essence, this is what the functions are already providing an
interface to: systems which take a truly random seed and output
pseudorandom values. The difference is that the underlying system is
designed to be cryptographically secure (for most uses). mt_rand(), on
the other hand, is not.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com