Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95975 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15178 invoked from network); 13 Sep 2016 07:19:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Sep 2016 07:19:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:39516] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/29-60695-D98A7D75 for ; Tue, 13 Sep 2016 03:19:59 -0400 Received: (qmail 103647 invoked by uid 89); 13 Sep 2016 07:19:54 -0000 Received: from unknown (HELO mail-qk0-f176.google.com) (yohgaki@ohgaki.net@209.85.220.176) by 0 with ESMTPA; 13 Sep 2016 07:19:54 -0000 Received: by mail-qk0-f176.google.com with SMTP id z190so156416289qkc.3 for ; Tue, 13 Sep 2016 00:19:54 -0700 (PDT) X-Gm-Message-State: AE9vXwOLItLu9fT76vVKIeoGWe/6PwrNVwu/SXbR+dnSuXPVL2rB0DhC3ELx1dcTEZHhZlB0siwIeOFZGZb2gQ== X-Received: by 10.55.184.198 with SMTP id i189mr24104394qkf.96.1473751188299; Tue, 13 Sep 2016 00:19:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.84.168 with HTTP; Tue, 13 Sep 2016 00:19:07 -0700 (PDT) In-Reply-To: <877fagwc5o.fsf@lil.giraffy.jp> References: <878tuxenl4.fsf@lil.giraffy.jp> <87twdlcs2j.fsf@lil.giraffy.jp> <87h99lch13.fsf@lil.giraffy.jp> <877fagczci.fsf@lil.giraffy.jp> <87mvjcbfcb.fsf@lil.giraffy.jp> <877fagwc5o.fsf@lil.giraffy.jp> Date: Tue, 13 Sep 2016 16:19:07 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Kazuo Oishi Cc: "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 Kauzo, On Tue, Sep 13, 2016 at 3:23 PM, Kazuo Oishi wrote: >> Current implementation is good enough for most cases, but it can be better. > > I agree this legacy design API works good enough for most cases. > > So, I think it should not be changed in BC break way. I updated the RFC. 2nd parameter (more_entropy) is int now. - 0 for disable more entropy. (Compatible with current $more_entropy=FALSE) - 1 for 10 digits entropy. e.g. 1.23456789 (Compatible with current $more_entropy=TRUE) DEFAULT - 13 to 255 to number of entropy [0-v]{13,255} chars. e.g. 1234abcdefghi (13 = 65 bits) 65 bits entropy + timestamp will provide good enough uniqueness for most usage. More secure default may be future scope, but attack against misused code will be much harder by default as a bonus. Default could be more secure by using [0-v]+. Marco does not like "." in default output. I would like to choose default from discussion (or make some vote choices) Current behavior is not an option because whole point of this RFC is to make uniqid() to return unique ID almost always even when system clock is adjusted. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net