Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95999 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46101 invoked from network); 14 Sep 2016 18:17:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2016 18:17:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=oishi@giraffy.jp; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kazuo@o-ishi.jp; sender-id=pass Received-SPF: pass (pb1.pair.com: domain giraffy.jp designates 49.212.134.110 as permitted sender) X-PHP-List-Original-Sender: oishi@giraffy.jp X-Host-Fingerprint: 49.212.134.110 www7096uf.sakura.ne.jp Received: from [49.212.134.110] ([49.212.134.110:54372] helo=xii.giraffy.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/88-21040-E3499D75 for ; Wed, 14 Sep 2016 14:17:35 -0400 Received: from localhost (localhost [127.0.0.1]) by xii.giraffy.jp (Postfix) with ESMTP id 88CF67A81A7; Thu, 15 Sep 2016 03:17:30 +0900 (JST) X-Virus-Scanned: amavisd-new at giraffy.jp Received: from xii.giraffy.jp ([127.0.0.1]) by localhost (xii.giraffy.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS7tSmqLXmR5; Thu, 15 Sep 2016 03:17:28 +0900 (JST) Received: from lil.giraffy.jp (aa024044.ppp.asahi-net.or.jp [110.5.24.44]) by xii.giraffy.jp (Postfix) with ESMTPSA id CADEC7A8196; Thu, 15 Sep 2016 03:17:28 +0900 (JST) To: Yasuo Ohgaki Cc: "internals\@lists.php.net" In-Reply-To: (Yasuo Ohgaki's message of "Tue, 13 Sep 2016 16:19:07 +0900") 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> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Thu, 15 Sep 2016 03:17:28 +0900 Message-ID: <87vaxyuz0n.fsf@lil.giraffy.jp> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness From: kazuo@o-ishi.jp (Kazuo Oishi) Hi, > 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) Basically, I will not oppose if backward compatibility is kept (default $number_of_entropy_chars = 0). I have no opinion about specifying length of entropy chars. However, I don't think this new 2nd parameter design is good. - It is not natural (or straightforward) to specify 1 as parameter named $number_of_entropy_chars, to use 10 digits entropy ($more_entropy=TRUE compatible output). - Why number of new style entropy ([0-9a-v]+) starts with 13? (Why not 2 or 11?) - Why max number of entropy is 255? (32^255 = 1275 bits) (Ease of implementation?) And, what will happen when 2-12, greater than 255, or negative value is specified? -- Kazuo Oishi