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.
# 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.
# 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.
# 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?
# 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?
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.
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.
Tom
