Re: Extending uniqid() or not?
On Feb 2, 2014 11:09 PM, "Yasuo Ohgaki" <[email protected]> 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
Thread (29 messages)