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

Hi, > 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? -- Kazuo Oishi