Re: Extending uniqid() or not?

On Feb 2, 2014 11:09 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote: > User may use it. IV should be random bytes and it can be used as > secure source for hash. I does almost the same thing that I would > like to do. Issues are > > - it does not auto detect RNG and use /dev/random by default > - it does not support /dev/arandom > - it uses php_rand() to create random bytes if source option is not RANDOM > or URANDOM > - it is not an available function by default... > > 1st issue is not a issue actually. I think this is good that it uses > /dev/random by default > even if it may block script. As a crypt module, it should use most secure > source by default. We may improve mcrypt_create_iv() a little by raising > E_NOTICE > error when user set source other than RANDOM or URANDOM, and add ARANDOM > as a source. > > Even though mcrypt_create_iv() good enough for it's original purpose, it's > not good as > a general (fool proof) method for generating random bytes as it can block > script execution. It is exactly because of of its blocking nature when the entropy source is not sufficient that it is secure. This is the root difference between urandom and random (or the likes). > My question is if we should extend uniqid() or add new function that > actually > generates safe ID string. We may add more description to uniqid() page, > mcrypt and However we really do not crypto safe random bytes for this purpose. urandom and similar are enough for session hash data or unique id. Non crypto safe RNGs are not necessary unsafe, only not safe enough for cryptography related operations, unique IDs is not a cryptography related operation. > Do you prefer documentation rather than extending uniqid() or new function? I think better documentation is a good solution. Cheers, Pierre