Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Thu, Sep 15, 2016 at 3:17 AM, Kazuo Oishi <kazuo@o-ishi.jp> wrote: >> I updated the RFC. >> 2nd parameter (more_entropy) is int now. >> >> - 0 for disable more entropy. >> (Compatible with current $more_entropy=FALSE) >> - 1 for 10 digits entropy. e.g. 1.23456789 >> (Compatible with current $more_entropy=TRUE) DEFAULT >> - 13 to 255 to number of entropy [0-v]{13,255} chars. >> e.g. 1234abcdefghi (13 = 65 bits) >> 65 bits entropy + timestamp will provide good enough uniqueness for >> most usage. >> >> More secure default may be future scope, but attack against misused >> code will be much harder by default as a bonus. >> >> Default could be more secure by using [0-v]+. >> Marco does not like "." in default output. >> >> I would like to choose default from discussion (or make some vote choices) > > Basically, I will not oppose if backward compatibility is kept (default > $number_of_entropy_chars = 0). I have no opinion about specifying > length of entropy chars. > > However, I don't think this new 2nd parameter design is good. > > - It is not natural (or straightforward) to specify 1 as > parameter named $number_of_entropy_chars, to use 10 digits > entropy ($more_entropy=TRUE compatible output). > > - Why number of new style entropy ([0-9a-v]+) starts with 13? > (Why not 2 or 11?) > > - Why max number of entropy is 255? (32^255 = 1275 bits) > (Ease of implementation?) > > And, what will happen when 2-12, greater than 255, or negative > value is specified? I'm going to propose more compatible fix that does not change length of entropy chars nor parameter type. Anyway, I was thinking to raise error for any invalid numbers. I'm going to propose A. Current format (digits and . e.g. 1.23456788) B. HEX format ([0-9a-f]{10}) I'll make these vote options. A is compatible with when $more_entropy=TRUE. B uses compatible chars without $more_entropy (=FALSE). Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net