Hi Rowan, On Mon, Sep 12, 2016 at 10:47 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > > uniqid() has never been, and is not claimed to be, guaranteed unique to any > particular standard.
Right. We need to improve documentation. It only has crypt related usage warning now. > On 12/09/2016 13:08, Yasuo Ohgaki wrote: >> >> Since we have to change "more entropy" to TRUE by default > > > Is your intention that the version without "more entropy" be deprecated, and > at some point the option removed? Or do you just want to increase the > visibility of this option by enabling it by default? I don't think we should remove "more entropy" option now, but it may be preferred. Currently, I'm proposing "more entropy" by default and use of better entropy source. > > In other words, do you consider the function to be broken / useless if this > option is not set to true? Or do you think users don't understand when to > use it and when not? It's useful. It's works as serial ID in most cases. Apparently, some users don't understand what is does. Some of them are fatal misusages. > >> why not use much better entropy? php_combined_lcg() is legacy entropy >> generator >> _must not_ be used now. New code's entropy is more than a million >> times better for the same length. 50 bits entropy is far less enough for >> crypt safety, though. > > > What costs and benefits will users see of changing the entropy generator? > Does it make uniqid() collisions less likely, and if so what kind of > probability are we talking about? Does it have a speed or memory cost (over > the existing more_entropy version, i.e. ignoring sleep)? I pasted simple benchmark to the PR. New code uses about 2x cpu time on my Fedora 24. CSPRNG uses more complex code than php_combined_lcg(), so this is expected. > Even if we accept a) that the default parameters should be changed, and b) > that the source for "more entropy" should be changed, I'm not clear why the > output format also needs to change. Is there some reason the output of > php_random_bytes() can't be encoded into decimal digits, rather than [0-v]? If I encode php_random_bytes() to the same length of digits, it does not increase entropy space. It remains about a million (a little less than 10 bits). It's too small for current baseline. Proposed code has 50 bits entropy. Besides php_combined_lcg() is based on system time. Therefore, it is extremely poor entropy source for uniqid() which generates timestamp string. It's more than a million times better entropy than now. Since uniqid() has timestamp string prefix, collision is unlikely and very close to 0, it's much more reliable than now. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
