Hi Leigh, On Sun, Jan 22, 2017 at 6:40 PM, Leigh <lei...@gmail.com> wrote:
> On Sat, 21 Jan 2017 at 14:41 Niklas Keller <m...@kelunik.com> wrote: > >> Anyway, the "issue" with mt_rand is not the seed being predictable but >> the internal state being recoverable from the output. But mt_rand is >> predictable by design, so why should we even seed it with a CSPRNG by >> default? >> >> >> For the record, when I was making RNG changes for 7.1, I did look at the > mt_rand seed mechanism, and decided it was _good enough_ for the purposes > of mt_rand. > > State recovery can actually be done with as few as 624 sequential outputs, > you will never be able to get away from that. Even with a fully CSPRNG > generated state, if an attacker gets 624 outputs after the state is > twisted, the RNG is compromised. > Nice comment! Since mt_rand is predictable PRNG, there is possibility to be known to attackers always. What I would like to change is - there is only 2^32 initial states Think of a code that generates "random password string" from mt_rand. (We know nobody should do this, but there are many codes do this) If password is alpha numeric+#$ and 10 chars long, there could be 64^10 = 2^60 patterns with pure random. but with current mt_rand could generate only 2^32 patterns due to mt_rand() limited state. This is a lot less random than it could be. Hardening mt_rand() w/o salt value beneficial to general mt_rand() usage also. i.e. PHP app runs short periods of time and only use beginning of MT rand cycle. More than 99% random cycle is wasted currently. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
