Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <511CB314-6F31-48AA-B3E1-6E0455C0D283@thefsb.org>
References: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org>
 <CAGa2bXZYStrud9MWya-680Z457T1i-a2F5u-AXtaNvkTdMEZtQ@mail.gmail.com>
 <CAGa2bXZRT2xGgL7fMkHFetjDk00w=AMmaCipVeM5Oftvd0mYAw@mail.gmail.com>
 <8991137d8dd8ba915bcacd4fbc1fe88f@gmail.com> <CAGa2bXYBV8cUBDXf5j2ZG6wDxDtTG1389JKNWJNi8-YT5FHupQ@mail.gmail.com>
 <CAGa2bXYw70SzxpicASH-Go5XPy4FJb2gnyuoJuYm=f3+dzB52A@mail.gmail.com>
 <CAGa2bXa97GVG-FxB-NDm4rVTKC+w8hUwFi-v0Kann_F_rEKKxA@mail.gmail.com> <511CB314-6F31-48AA-B3E1-6E0455C0D283@thefsb.org>
Date: Fri, 3 Feb 2017 08:16:00 +0900
Message-ID: <CAGa2bXY=40S8UXo3M8nnkZ3tyAqgo1AccGe-Pa44CPCfxKP18w@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, Leigh <leight@gmail.com>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a1148a27aa3859f0547945b72
Subject: Re: [PHP-DEV] Improving mt_rand() seed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1148a27aa3859f0547945b72
Content-Type: text/plain; charset=UTF-8

Hi Tom,

On Fri, Feb 3, 2017 at 2:53 AM, Tom Worster <fsb@thefsb.org> wrote:
>
> On 1 Feb 2017, at 22:47, Yasuo Ohgaki wrote:
>
> Posting RFC draft before discussion
>
> https://wiki.php.net/rfc/improve_predictable_prng_random
>
> This RFC includes results of recent PRNG related discussions.
> I would like to keep it simple, but basic object feature will be
> implemented.
>
> Methods could raise exceptions for invalid operations rather than
ignoring.
>
> Comments?
>
> I don't see in it any results of recent PRNG related discussions. I only
see your ideas and a disregard for other opinions.

Incorrect. See "Reseeding rand()/mt_rand()" thread.
My initial idea was to separate rand() and mt_rand().
Andrea suggests user and system state should be separated and I agree.
Therefore, current RFC is written.

>
> 1 The very first sentence
>
> "Current predictable PRNG, i.e. mt_rand() and rand(), produces very weak
random values even produces non random values."
>
> is plain nonsense. mt_rand implements the Mersenne Twister 19937 with
32-bit seed. It's a standard algorithm that's been used widely. It does
exactly what it's supposed to do.
>
> The idea that it produces "very weak random values" expresses your
obsession with its use to produce unpredictable values, which it cannot
possibly do. Nobody else is trying to make it do this.

How could you say current MT rand usage is strong as it could/should?

There are 2^19937-1 states with MT rand, but we only use 2^32 (or less due
to LCG seed).
Current PHP usage is extremely weak obviously.

>
> 2 Purpose of object API
>
> You've misunderstood the idea of the "object-based PRNG interface". It's
purpose is not to instrument mt_rand internals but to introduce alternative
new generators. We concluded last year that there's very little we can do
about mt_rand without breaking BC and/or making more mess, so it should be
left to rot while we offer users something better. The new OOP API might
offer things like MT, Xorshift, PCG, legacy LCGs, or whatever you fancy
(maybe even MT-PHP :), distributions and utilities.

That's what the RFC does with minimal BC.
Swift even changes syntax, why not rare API usage?

>
> 3 This API
>
> Where to start? Have you any experience with the random APIs of any
decent statistical packages? Take a look at Boost Random, R, ...
>
> Who wants a low-level interface to the MT algorithm's internals?

I'm not trying to full featured API, but minimal API enough to fix mess.
Improvement suggestion for minimal API is welcomed.

>
> 4 "Fix" for abuse of mt_rand
>
> Your concern that people abuse mt_rand to get unpredictable values is
valid. But I don't think your attempts to mitigate this are useful.
>
> Hypothetically, say we take a radical approach and make mt_rand draw from
php_random_bytes by default on every call. How much good would it do?

I'm not proposing CSPRNG seed value for every mt_rand() calls, but CSPRNG
value use when initialization and reseeding, reseeding period is
configurable also.

What's good is written previously.
"There are 2^19937-1 states with MT rand, but we only use 2^32 (or less due
to LCG seed).
Current PHP usage is extremely weak obviously."

>
> Unmaintained legacy apps are unaffected because nobody upgrades them from
whatever PHP 4 or 5 they are on. Only apps that have stopped receiving
security updates but that are nevertheless actively maintained to migrate
them new major PHP versions can benefit. It's a niche we can better target
with new APIs and education. W.r.t. unpredictable randoms, that's already
done in 7.0.
>
> Hence I don't believe abuse of mt_rand is something we can fix by
modifying its behavior. It's too late.

IMO, nothing is too late.
We broke predictable PRNG in PHP 7.1. See other my reply in this thread.
This should be fixed ASAP.

>
> But if you really insist on doing something to mt_rand then make its
automatic seed use php_random_bytes and, if that fails, fall back to
GENERATE_SEED. While I doubt it will make the world any safer, it is as
effective as my hypothetical radical "fix" and should be harmless so long
as you don't introduce new bugs.

Basically, I'm trying to use MT rand with optimal usage. Safety is side
effect.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1148a27aa3859f0547945b72--