On 2017-02-02 05: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?
--
Yasuo Ohgaki
yohg...@ohgaki.net
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.
There's now three completely unrelated "issues":
1) You want to improve automatic seeding and GENERATE_SEED. You could
just generate a 32-bit value from php_random_bytes and silently use the
current as fallback; this solution was practically accepted already. You
just waste time with your arguments about CSPRNG being sooooo important:
everybody has already heard you, and most people seem to disagree.
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 PRNG object to avoid cases where some internal function (say,
shuffle) modifies 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
CSPRNG is not guaranteed to work so well.
--
Lauri Kenttä
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
