Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98124 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91963 invoked from network); 2 Feb 2017 17:53:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2017 17:53:39 -0000 Authentication-Results: pb1.pair.com header.from=fsb@thefsb.org; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=fsb@thefsb.org; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: fsb@thefsb.org X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Received: from [108.166.43.67] ([108.166.43.67:41451] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 11/DE-51557-12273985 for ; Thu, 02 Feb 2017 12:53:37 -0500 Received: from smtp1.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2560D201FF; Thu, 2 Feb 2017 12:53:34 -0500 (EST) X-Auth-ID: fsb@thefsb.org Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id C0F3320292; Thu, 2 Feb 2017 12:53:33 -0500 (EST) X-Sender-Id: fsb@thefsb.org Received: from [10.0.1.2] (c-66-30-62-12.hsd1.ma.comcast.net [66.30.62.12]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Thu, 02 Feb 2017 12:53:34 -0500 To: "Yasuo Ohgaki" Cc: "Lauri =?utf-8?q?Kentt=C3=A4?=" , "internals@lists.php.net" , Leigh , "Nikita Popov" Date: Thu, 02 Feb 2017 12:53:33 -0500 Message-ID: <511CB314-6F31-48AA-B3E1-6E0455C0D283@thefsb.org> In-Reply-To: References: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org> <8991137d8dd8ba915bcacd4fbc1fe88f@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0B24CA52-D530-4FD9-965A-38F86AB7C036_=" X-Mailer: MailMate (1.9.6r5319) Subject: Re: [PHP-DEV] Improving mt_rand() seed From: fsb@thefsb.org ("Tom Worster") --=_MailMate_0B24CA52-D530-4FD9-965A-38F86AB7C036_= Content-Type: text/plain; format=flowed On 1 Feb 2017, at 22:47, Yasuo Ohgaki wrote: > Posting RFC draft before discussion > > https://wiki.php.net/rfc/improve_predictable_prng_random > > This RFC includes results of recent PRNG related discussions. > I would like to keep it simple, but basic object feature will be > implemented. > > Methods could raise exceptions for invalid operations rather than > ignoring. > > Comments? I don't see in it any results of recent PRNG related discussions. I only see your ideas and a disregard for other opinions. # 1 The very first sentence "Current predictable PRNG, i.e. mt_rand() and rand(), produces very weak random values even produces non random values." is plain nonsense. mt_rand implements the Mersenne Twister 19937 with 32-bit seed. It's a standard algorithm that's been used widely. It does exactly what it's supposed to do. The idea that it produces "very weak random values" expresses your obsession with its use to produce unpredictable values, which it cannot possibly do. Nobody else is trying to make it do this. # 2 Purpose of object API You've misunderstood the idea of the "object-based PRNG interface". It's purpose is not to instrument mt_rand internals but to introduce alternative new generators. We concluded last year that there's very little we can do about mt_rand without breaking BC and/or making more mess, so it should be left to rot while we offer users something better. The new OOP API might offer things like MT, Xorshift, PCG, legacy LCGs, or whatever you fancy (maybe even MT-PHP :), distributions and utilities. # 3 This API Where to start? Have you any experience with the random APIs of any decent statistical packages? Take a look at Boost Random, R, ... Who wants a low-level interface to the MT algorithm's internals? # 4 "Fix" for abuse of mt_rand Your concern that people abuse mt_rand to get unpredictable values is valid. But I don't think your attempts to mitigate this are useful. Hypothetically, say we take a radical approach and make mt_rand draw from php_random_bytes by default on every call. How much good would it do? Unmaintained legacy apps are unaffected because nobody upgrades them from whatever PHP 4 or 5 they are on. Only apps that have stopped receiving security updates but that are nevertheless actively maintained to migrate them new major PHP versions can benefit. It's a niche we can better target with new APIs and education. W.r.t. unpredictable randoms, that's already done in 7.0. Hence I don't believe abuse of mt_rand is something we can fix by modifying its behavior. It's too late. But if you really insist on doing *something* to mt_rand then make its automatic seed use php_random_bytes and, if that fails, fall back to GENERATE_SEED. While I doubt it will make the world any safer, it is as effective as my hypothetical radical "fix" and should be harmless so long as you don't introduce new bugs. Tom --=_MailMate_0B24CA52-D530-4FD9-965A-38F86AB7C036_=--