Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocFZQdU2bt0OETeJMQYBXVUkK8ygB5jTb4ML3df4GZWdVA@mail.gmail.com>
References: <CAPwsocFZQdU2bt0OETeJMQYBXVUkK8ygB5jTb4ML3df4GZWdVA@mail.gmail.com>
Date: Wed, 15 Jun 2016 17:33:35 +0700
Message-ID: <CAEZPtU6B7xFoY_tSpxveUEWYF49e78sQ881GAT5WwOh_4Nd=Kg@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Jun 14, 2016 at 11:46 PM, Leigh <leight@gmail.com> wrote:
> Hey Internals,
>
> I realise I'm cutting it close with this one, but I want to propose some
> changes to our standard random number generators.
>
> The downside of this proposal is that our RNGs (rand() and mt_rand()) are
> seedable and reproduce identical streams (platform dependant) for any given
> seed. However their implementations are broken or inconsistent, so we need
> to weigh up the cost of changing these sequences versus having solid
> implementations.
>
> It is my opinion that if we are going to make any changes to these
> functions, we should make all of the changes at the same time and avoid any
> future disruption to their output.
>
> The RFC contains a few proposals, some of them depend on each other while
> others are standalone. Throughout the discussion phase I hope to reduce the
> number of proposals down to a consensus we can vote on in two weeks time.
>
> I will release a patch when I have a better feeling for the direction we
> want to take.
>
> The issues I want to bring up for discussion are.
>
> * Replacing mt_rand() and rand() to a strong, modern RNG.

I do not think this is a good option, if by strong you mean another kind of RNG.

> * Alternatively, fixing the current mt_rand() implementation to make it
> standard

That sounds more reasonable. An option (please no ini as it is a
programatic flow feature, not a php configuration problem) to keep the
old behavior for BC. Having to add an option for 7.1 or 7.2+ is
reasonable enough for the cases where the current seed and predictable
sequences are desired (same data generations for example using one
seed for example).

> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the array_rand() algorithm more efficient

Indeed

> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> If anyone knows of other fixes that should be made at the same time but I
> have overlooked, please let me know so I can get them included.

Also in the replies to this thread I see the word "crypto" mixed with
mt_rand/rand. It does not make sense to me. I agree that some apps
misused these functions as crypto safe RNG, some may even work around
issues and do not want to change their code to use reliable
alternatives. However this is a documentation/education issue. There
is no need to make mt_rand/rand crypto safe but there is a use for a
reliable implemantion of mt_rand.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org