Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6370f3c9-0904-bac9-0f9e-e563e9af9843@gmail.com>
References: <CAGa2bXYg1kkoYGQNr8T2oTshuqrvweefYO+EdY41w1vwUM32iQ@mail.gmail.com>
 <878tuxenl4.fsf@lil.giraffy.jp> <CAGa2bXaTydTSZniX4dUA9h_FcNaymyqfDXQJO0zx1ZDfLmvWdg@mail.gmail.com>
 <87twdlcs2j.fsf@lil.giraffy.jp> <CAGa2bXaziNMtNAgsJgX-BCgLL9z2WkoSaP8aNVrAgwo9MJ4WEQ@mail.gmail.com>
 <6370f3c9-0904-bac9-0f9e-e563e9af9843@gmail.com>
Date: Tue, 13 Sep 2016 10:07:24 +0900
Message-ID: <CAGa2bXaHagrquNw063jeJUX=vnnyOugMps881tbRgRaMJ2Ef-w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Rowan,

On Mon, Sep 12, 2016 at 10:47 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
>
> uniqid() has never been, and is not claimed to be, guaranteed unique to any
> particular standard.

Right. We need to improve documentation. It only has crypt related
usage warning now.

> On 12/09/2016 13:08, Yasuo Ohgaki wrote:
>>
>> Since we have to change "more entropy" to TRUE by default
>
>
> Is your intention that the version without "more entropy" be deprecated, and
> at some point the option removed? Or do you just want to increase the
> visibility of this option by enabling it by default?

I don't think we should remove "more entropy" option now, but it may
be preferred.

Currently, I'm proposing "more entropy" by default and use of better
entropy source.

>
> In other words, do you consider the function to be broken / useless if this
> option is not set to true? Or do you think users don't understand when to
> use it and when not?

It's useful. It's works as serial ID in most cases.

Apparently, some users don't understand what is does. Some of them are
fatal misusages.

>
>> why not use much better entropy? php_combined_lcg() is legacy entropy
>> generator
>> _must not_ be used now. New code's entropy is more than a million
>> times better for the same length. 50 bits entropy is far less enough for
>> crypt safety, though.
>
>
> What costs and benefits will users see of changing the entropy generator?
> Does it make uniqid() collisions less likely, and if so what kind of
> probability are we talking about? Does it have a speed or memory cost (over
> the existing more_entropy version, i.e. ignoring sleep)?

I pasted simple benchmark to the PR.
New code uses about 2x cpu time on my Fedora 24. CSPRNG uses more complex
code than php_combined_lcg(), so this is expected.

> Even if we accept a) that the default parameters should be changed, and b)
> that the source for "more entropy" should be changed, I'm not clear why the
> output format also needs to change. Is there some reason the output of
> php_random_bytes() can't be encoded into decimal digits, rather than [0-v]?

If I encode php_random_bytes() to the same length of digits, it does
not increase entropy space. It remains about a million (a little less
than 10 bits).  It's too small for current baseline.

Proposed code has 50 bits entropy. Besides php_combined_lcg() is based
on system time. Therefore, it is extremely poor entropy source for
uniqid() which generates timestamp string. It's more than a million
times better entropy than now. Since uniqid() has  timestamp string
prefix, collision is unlikely and very close to 0, it's much more
reliable than now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net