Re: Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
| From: | Leigh | Date: | Wed, 05 Oct 2016 08:25:48 +0000 |
| Subject: | Re: Re: [RFC][DISCUSSION] Improve uniqid() uniqueness | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96245@lists.php.net to get a copy of this message | ||
The list was missed off of Yasuo's replies to me, replying including the
list
On Wed, 5 Oct 2016 at 01:07 Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Leigh,
>
> On Tue, Oct 4, 2016 at 7:06 PM, Leigh <leight@gmail.com> wrote:
> > Since we want to preserve BC
> >
> > entropy = random_int(0, 99999999);
> > uniqid = strpprintf(0, "%s%08x%05x.%08d", prefix, sec, usec, entropy);
>
> Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> has [0-9].[0-9]{8} format.
>
> "F"->"d" does not work. It should be something like
>
> entropy = (double) random_int(0, 9999999999);
>
No it shouldn't. Don't do this. It is an unnecessary conversion. The fact
the lcg returns a double is irrelevant. What is relevant is the 8 digits in
order to maintain BC. The 8 digits you receive from random_int will still
be higher quality than the 10 you get from the lcg rounded to 8 places.
> uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/100000000);
>
On Wed, 5 Oct 2016 at 01:16 Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> On Wed, Oct 5, 2016 at 9:06 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> > has [0-9].[0-9]{8} format.
> >
> > "F"->"d" does not work. It should be something like
> >
> > entropy = (double) random_int(0, 9999999999);
> > uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/100000000);
>
> Forgot to mention, this code leak more information about PRNG state
> than my patch because php_random_int() copies random binary data into
> long. It's still part of it and exposure of random data shouldn't
> matter, so this is minor issue.
>
I think there is a misunderstanding here. You're using the CSPRNG which is
designed such that the _entire_ output can be made public without you being
able to predict the next result. That is the definition of a CSPRNG. Also
remember this is "output" not "state".
While researching how to implement these CSPRNG functions, I spoke with
real security experts on the subject, they all said the same thing: Use the
system CSPRNG, and yes, it is fine to expose the output directly.
Also if you really are worried (which you shouldn't be), requesting 8
digits from random_int will effectively discard 5 or 37 bits of output
depending on whether you're on a 32 or 64 bit platform. You cannot know the
value of sequential outputs.
> I'll update gist.
> Any more comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net