Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
Message-ID: <54B3F290.3050909@gmail.com>
Date: Mon, 12 Jan 2015 08:13:04 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 PHP Internals List <internals@lists.php.net>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me> <54B30DB9.3000003@seld.be> <76B8D342-43E7-42E6-AD82-FCF7C5CA8658@ajf.me> <54B31D77.9010100@gmail.com> <976B7B2E-7BC9-4514-ABF3-C0DA3ED98897@ajf.me> <54B32145.80501@gmail.com> <B3E640CE-0361-4132-A849-20AFFC9D7AA8@ajf.me> <54B32BEA.5090507@gmail.com> <54B38EA6.8070402@lerdorf.com> <47FF88D5-14F8-4844-A9DD-51532FBF3588@ajf.me> <A45E87D8-FBF7-41F5-BB25-CAC08E3CA84B@ajf.me>
In-Reply-To: <A45E87D8-FBF7-41F5-BB25-CAC08E3CA84B@ajf.me>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>> - To produce a repeatable sequence of random numbers (works, but
>> only if you and the sole user of the global random number
>> generator, which is not guaranteed by any means)

If you write your code it is guaranteed. Note that it's not some API
we're designing out of the blue, it is something that has been working
for years and you propose to just eliminate it because you don't like
it. It's not how it should be done in a mature language like PHP. If you
want to design better API, please do it, but breaking working APIs is
not a good idea.

> - To generate cryptographic keys - a seeded random number generator

I'm surprised you even bring it up. Yes, it is known rand() should not
be used for cryptography. It is true with srand or without srand, and
nobody advocated using rand for cryptography.

> This is why Suhosin disabled srand by default: it is, unfortunately,
> also a security issue.

Saying "it's a security issue" is not some magic phrase that instantly
makes wrong into right. There's no security issue in srand. Security
issue is in wrong usage of rand() and breaking srand() would do nothing
to fix it. If you use a tool for a wrong purpose, it is pointless to
point each aspect of it and say "that's where the wrong is" if the whole
thing altogether is wrong from the premise up.
-- 
Stas Malyshev
smalyshev@gmail.com