Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98035
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: <CAGa2bXZRT2xGgL7fMkHFetjDk00w=AMmaCipVeM5Oftvd0mYAw@mail.gmail.com>
References: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org>
 <CAGa2bXZYStrud9MWya-680Z457T1i-a2F5u-AXtaNvkTdMEZtQ@mail.gmail.com> <CAGa2bXZRT2xGgL7fMkHFetjDk00w=AMmaCipVeM5Oftvd0mYAw@mail.gmail.com>
Date: Mon, 30 Jan 2017 13:33:40 +0900
Message-ID: <CAGa2bXaMWKiN3vqAVXeHc1+DeeA-a8vJpR_isBuYiF010xWmzg@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>, =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>, 
	Leigh <leight@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a1145bd0c51a17405474854f4
Subject: Re: [PHP-DEV] Re: Improving mt_rand() seed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1145bd0c51a17405474854f4
Content-Type: text/plain; charset=UTF-8

Hi all,

On Mon, Jan 30, 2017 at 11:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Our part could be fixed by us. Let's fix it now.
>
> Lauri made patch for unseeded mt_rand(). I'll prepare patch that allows
> int array
> initialization for mt_srand() so that whole state buffer can be
> initialized as user specifies.
>
> void mt_srand(int|array $seed)
>
> where $seed could be
>
> $seed = [123456789, 987654321, ....]; // Up to max size of state buffer
>
> It can be said current mt_rand() is good enough for the purpose. I totally
> agree with this.
> However, I cannot agree that current mt_rand() implementation is
> ideal/what it should be.
>

Seed is very important for PRNG and current seeding code/behavior has other
issues.


First issue is:

1) PHP does not care if seed is done by "user" or "system"(lcg random now).
2) If user seed by mt_srand(1234), then the seed is outstanding for
mt_rand()/rand() calls across requests.

Most users would expect "random seeding" when there is no
mt_srand()/srand() in current execution while currently is not.

I think of 2 choices to fix this behavior:

1) Set BG(mt_rand_is_seeded) = 0 by RINIT always and force to reseed by
system when it is applicable.
2) Add new BG(mt_rand_is_user_seeded) flag if it is 1,
BG(mt_rand_is_seeded) = 0 by RINIT. (A little efficient than 1)

Thoughts?


In addition to previous issue, rand()/srand() is alias of
mt_rand()/mt_srand() now. Most developers
expect rand() and mt_rand() as unrelated PRNG and may write following code

srand(1234);
$rnd = rand(); // We need the same rand() for XXX

Somewhere in other code in the same app,

$rnd = mt_rand(); // We need hard to predict non CS purpose random here.

Obviously, the mt_rand() call is not random at all.
This affects all of MT rand usage such as shuffle(), etc.

Instead of sharing the same MT rand state, it may be better to have
dedicated state for rand()/srand() at least.

There are few functions use MT rand like shuffle(), but I would like to
avoid to allocate state buffers for each MT rand usage. One possible
resolution may be adding reseed flag to srand()/mt_srand().

// Force system reseeding
srand(TRUE);
mt_srand(TRUE);

then users may be used as follows

// Need randomness that is not affected by other parts of codes. i.e.
srand(123)/mt_rand(123) somewhere else.
mt_srand(TRUE);
shuffle($my_random_array);

I don't like this idea myself. I don't like seeding flag for shuffle()/etc
neither. Writing code is easy, but this issue is not easy to fix.
Any better ideas?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1145bd0c51a17405474854f4--