Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98118
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: <1fa97f9f4d4c0866fb4b0f21fc68b068@gmail.com>
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> <1fa97f9f4d4c0866fb4b0f21fc68b068@gmail.com>
Date: Thu, 2 Feb 2017 20:51:47 +0900
Message-ID: <CAGa2bXakeme3h6RgqYWtJ+usJ6YwjJf7LkHaj=yVQXHWkdx+6w@mail.gmail.com>
To: =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>
Cc: Tom Worster <fsb@thefsb.org>, "internals@lists.php.net" <internals@lists.php.net>, Leigh <leight@gmail.com>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c070ec8a6c7e705478accf1
Subject: Re: [PHP-DEV] Re: Improving mt_rand() seed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--94eb2c070ec8a6c7e705478accf1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Lauri,

On Thu, Feb 2, 2017 at 6:54 PM, Lauri Kentt=C3=A4 <lauri.kentta@gmail.com> =
wrote:

> I think this RFC is badly prepared. You're overhauling the whole mt_rand
> system in one go, but you're not doing it properly. There is no
> justification for breaking compability, not in 7.x and not even in 8.0 in
> my opinion.
>

Which part are you referring as BC? I suppose it is

<?php
$state =3D mt_srand(1234);
mt_rand($state); // Get static seed result
?>

Current behavior is extremely bad because if there is srand()/mt_srand()
call in execution path.

1) When seed is provided to srand()/mt_srand(),
consecutive rand()/mt_rand() calls became non random. (Unacceptable)
2) 1) applies to across request. (Extremely bad)
3) Even without seed, srand()/mt_srand() call makes guess a lot easier than
it should be. i.e. Combined LCG is weak.

Suppose attacker find execution path that has static seed for
srand()/mt_srand(), then attacker can predict exact random or can guess
easily.

a.php
<?php
// I need static random sequence
srand(1234);
for ($i =3D 0; $i < 10; $i++)
  $rand[] =3D rand();
?>

b.php
<?php
// I need random sequence, let PHP seed it
for ($i =3D 0; $i < 10; $i++)
  $better_rand[] =3D mt_rand();
?>

If a.php is called, then b.php's mt_rand() is not random at all.

Even if mt_rand()/rand() is predictable, this kind of behavior is
_ABSOLUTELY_ unacceptable. IMO.

It's BC, but how many srand()/mt_srand() calls are used in real apps?
I know there are, but benefits outweighs BC impact.


>
> There's now three completely unrelated "issues":
>
> 1) You want to improve automatic seeding and GENERATE_SEED. You could jus=
t
> generate a 32-bit value from php_random_bytes and silently use the curren=
t
> as fallback; this solution was practically accepted already. You just was=
te
> time with your arguments about CSPRNG being sooooo important: everybody h=
as
> already heard you, and most people seem to disagree.
>

True, but I've never heard of CSPRNG failure that could cause BC that
matter as PHP problem yet.


>
> 2) You want to support long seeds. However, 2^32 is a lot of random
> states. It's enough for almost any legitimate MT use case. As was earlier
> discussed, adding this support to the global mt_srand is not practical.
> Anyone who really needs a longer seed should most probably also use a PRN=
G
> object to avoid cases where some internal function (say, shuffle) modifie=
s
> the MT state by accident.
>
> 3) You want to use long seeds by default. This would be possible, as
> discussed earlier, by seeding the whole MT state buffer from a CSPRNG.
> However, you should consider also the possible performance impact of
> generating 2,5 kB from CSPRNG on each request/reseed. And again, 2^32 is
> probably enough already.
>

> FWIW, my Raspberry Pi kernel log has several lines about /dev/urandom not
> being properly seeded before the system is fully started, so using a CSPR=
NG
> is not guaranteed to work so well.
>

Although users must never do this, but there are codes that generate random
password/access key by mt_rand().

If algorithm is known to attacker, all attacker should do could be making
very small size of dictionary
or current computer is fast enough to compute next random string to be
generated in short enough time.
If MT rand is seed fully, above task becomes hard enough task attackers to
avoid attacks.

Reading data from CSPRNG shouldn't be too slow as you know. One in a
hundred calls shouldn't matter. Even when it could matter, users may set
PHP to reseed one in a million, but the default shouldn't be too large.

When hardware TRNG is not available, CSPRNG could generate poor random
until system corrects enough entropy events. i.e. matter of time. CSPRNG
output should be available. If not, I'm surprised and I'll change my
opinion.

How many mt_rand()/rand() calls are executed during PHP process
lifetime? With 32 bits seed, users will never use even 0.0000000000000001%
of MT rand potential. It's too much waste of the algorithm, isn't it?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--94eb2c070ec8a6c7e705478accf1--