On Tue, Jun 14, 2016 at 11:46 PM, Leigh <lei...@gmail.com> wrote: > Hey Internals, > > I realise I'm cutting it close with this one, but I want to propose some > changes to our standard random number generators. > > The downside of this proposal is that our RNGs (rand() and mt_rand()) are > seedable and reproduce identical streams (platform dependant) for any given > seed. However their implementations are broken or inconsistent, so we need > to weigh up the cost of changing these sequences versus having solid > implementations. > > It is my opinion that if we are going to make any changes to these > functions, we should make all of the changes at the same time and avoid any > future disruption to their output. > > The RFC contains a few proposals, some of them depend on each other while > others are standalone. Throughout the discussion phase I hope to reduce the > number of proposals down to a consensus we can vote on in two weeks time. > > I will release a patch when I have a better feeling for the direction we > want to take. > > The issues I want to bring up for discussion are. > > * Replacing mt_rand() and rand() to a strong, modern RNG.
I do not think this is a good option, if by strong you mean another kind of RNG. > * Alternatively, fixing the current mt_rand() implementation to make it > standard That sounds more reasonable. An option (please no ini as it is a programatic flow feature, not a php configuration problem) to keep the old behavior for BC. Having to add an option for 7.1 or 7.2+ is reasonable enough for the cases where the current seed and predictable sequences are desired (same data generations for example using one seed for example). > * Replacing insecure uses of php_rand() with php_random_bytes() > * Making the array_rand() algorithm more efficient Indeed > The RFC can be found here: https://wiki.php.net/rfc/rng_fixes > > If anyone knows of other fixes that should be made at the same time but I > have overlooked, please let me know so I can get them included. Also in the replies to this thread I see the word "crypto" mixed with mt_rand/rand. It does not make sense to me. I agree that some apps misused these functions as crypto safe RNG, some may even work around issues and do not want to change their code to use reliable alternatives. However this is a documentation/education issue. There is no need to make mt_rand/rand crypto safe but there is a use for a reliable implemantion of mt_rand. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
