UniqID source not binary

[Beanow]

I noticed an off thing about the UniqID source compared to the other sources.
The output format is not in full binary range, but is in the hexadecimal range plus a few dots.

Was this deliberate?
And why, for example is the dot not removed? It's a very predictable part of the output and seems to me, basically wastes locations in the $size of requested characters.

UniqID may be geared towards collision prevention, but when used as a source of entropy, shouldn't it be ok to use a hashing function?

[ircmaxell]

It's never used by itself as an entropy source. It's always paired with at least one or two others. It wasn't intended to provide strong randomness, just more entropy. And given that the mixing strategies will use entropy without leaking information (like predictable location of characters), it should be secure as is

With that said, it wouldn't be bad to encode the result as binary. Just not necessary for security. Therefore, I'll leave this open.

[Beanow]

True, uniqid is not sufficient as a sole source of entropy. Still in the current setup, every 1 in 23 bytes will be overhead from the dot. And the character range seriously waters down the 'density' of the data. For the sake of having abstract and predictable interfaces it would be nice to have this dot removed or use a hash so the dot in the input becomes irrelevant.

Or another method is to parse the UniqID format and converting it to binary 1:1.
This would save some CPU and provide the same amount of entropy compared to hashing.
Something along the lines of this:

$binary = '';
do{
  $sections = explode('.', uniqid('', true));
  $binary .= hex2bin($sections[0]);
  $binary .= pack('L', (int)$sections[1]);
}
while(strlen($binary) < $size);

return substr($binary, 0, $size);

//Sample output ($size=40): RD�y��4�ϳ�RD�y���eG7�RD�y��u >�RD�y��