Hi Tom, On Fri, Feb 3, 2017 at 2:53 AM, Tom Worster <f...@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 yohg...@ohgaki.net
