Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83697
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: <CAAyV7nHE_Y-H-m5sgZTM=q-MKDXg0ycitTN+--0bPBQcSd8T2g@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>
Date: Tue, 24 Feb 2015 12:54:03 -0800
Message-ID: <CAEZPtU4HxYs-iRJFGhucf7UzbUBZ3VZ1gjxgVBCJjURwUD-oUQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Sammy Kaye Powers <me@sammyk.me>, Leigh <leight@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136feb61f810b050fdbb8ba
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG
From: pierre.php@gmail.com (Pierre Joye)

--001a1136feb61f810b050fdbb8ba
Content-Type: text/plain; charset=UTF-8

On Feb 24, 2015 12:04 PM, "Anthony Ferrara" <ircmaxell@gmail.com> wrote:
>
> Pierre,
>
> >> In fact I had planned for a future RFC where we allow
> >> session.entropy_file to use using random_bytes(). So the "best" source
> >> is chosen automatically. (If you think there are better sources not
> >> covered by this patch, please let me know, I would like it to be
> >> complete)
> >
> > I rather prefer to be able to choose. Maybe make it system instead of
> > INI_ALL if the users ability to choose wisely are questionable.
>
> Why? Why should the user change their entropy location? What benefits
> (especially from only a system perspective) does that provide to
> users/sysadmins?
>
> Besides letting an admin decrease the security of a security API?

Increase is the point and it is one of the  reasons why we made a setting
for the session entropy.

> >> There is an aspect of this that has been left for "future work", but
> >> if the list thinks it is important I can implement it for this RFC.
> >> The issue is that on Linux it still does not provide a way of getting
> >> random bytes without using a file descriptor. This is important for a
> >> couple of reasons, 1) It means chroot environments don't require
> >> /dev/*random 2) it prevents fd-exhaustion attacks that force lower
> >> quality randomness. LibreSSL-portable has a very good implementation
> >> of this using the Linux getrandom syscall (Kernel >= 3.17) that I can
> >> phpise and include if we think it is necessary.
> >
> > It is all the same setting. What is done on windows can be applied on
any
> > other platforms. Either use a path or a method, it just works fine.
> >
> > There are many different RNG providers, daemons or other services. I
have
> > seen customers using some of them (together) to generate enough data for
> > their needs (need a lot of entropy data). By enough data I mean to be
200%
> > sure that the entropy is good enough at any time no matter how much
data is
> > being fetched.
>
> Yes, and they all can feed into /dev/arandom and /dev/urandom. In fact
> that's how those systems are designed to operate (taking in entropy
> from many sources).

Not always. And not always desired. Also as pointed out in a another reply
it could be an API (but that goes for a next step about this feature).

> 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.

> I think one of the mistakes that password_hash made was exposing the
> salt to the user. If you give users a choice with respect to security,
> they will on average make it worse (based on plenty of code snippets
> I've seen, that's the case with salt generation).
>
> I think the case you have to look at here is the target audience. Are
> you looking to be all things to all users? Or are you attempting to be
> an opinionated tool to help the 99%. Along with password_hash, I think
> this random library serves the 99%.
>
> It shouldn't try to be all things to everyone, because then it will
> confuse or complicate things for the 99%. The reality is we've been
> lacking a simple API for years. Seeing what users implement in the
> wild shows that.
>
> To quote a phrase I coined years ago: It should be easier to get right
> than to screw up. And that includes using existing APIs.
>
> So if random_int() is harder than mt_rand(), it's a non-starter.
>
> If random_bytes() is harder than uniqid(), it's a non-starter.
>
> > I am also unsure about random_get_int, why only integer? It is also
> > important that doing so the results is per se not crypto safe anymore.
But
> > still handy for codes required random integers (or other types). If it
is
> > kept, I would also prefer to name it random_get_<type> instead, for
clarity.
>
> How is it not crypto safe? It uses a non-biased algorithm using a
> crypto-safe primitive.
>
> As far as why only integer, a float can always be added to. But
> strings are already supported, and what other types do you need?

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.

> That's my stance at least.
>
> Anthony
I

--001a1136feb61f810b050fdbb8ba--