Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4aRjVNrpBnnsHdmvXAR_bSNV4LukObyJfD2P_oHHyubg@mail.gmail.com>
References: <BE8DBAE8-8B03-4834-8553-90DB69B0CD54@rouvenwessling.de>
	<CAEZPtU4aRjVNrpBnnsHdmvXAR_bSNV4LukObyJfD2P_oHHyubg@mail.gmail.com>
Date: Thu, 27 Feb 2014 22:30:48 +0000
Message-ID: <CALwr1Gk-WXTsfy78o05B1wuKrhV1XFMebjYXpwbWboQdZUYr9g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: =?UTF-8?Q?Rouven_We=C3=9Fling?= <me@rouvenwessling.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PHP6] Merging rand and mt_rand()
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi,

On 26 February 2014 08:13, Pierre Joye <pierre.php@gmail.com> wrote:
> Hi Rowen,
>
>
> On Sun, Feb 23, 2014 at 7:45 PM, Rouven We=C3=9Fling <me@rouvenwessling.d=
e> wrote:
>> Hello internals,
>>
>> there has already been a lot of talk about improving secure random numbe=
r generation for PHP6. One thing I'd like to improve as well, would be non-=
secure random number generation. Here is not so much security at stake but =
ease of use.
>>
>> The obvious solution, would be to rename mt_rand to rand and make rand a=
n alias. (The same for the supporting functions mt_srand and mt_getrandmax)=
.
>>
>> What I'm missing is the history. What was the reason to keep the separat=
e? Am I missing something?

Well, they do two different things so keeping them separate seems like
a good idea ;).

> I totally agree with your goals. There are too many ways to do the
> same operations, in many areas. However I am not a fan of breaking BC
> (even in small ways) without an actual big benefit. It is always easy
> to remove, kill, change functions to make them "better". Adding each
> single change together will make a migration to a given version almost
> impossible or very painful. I would go with a soft way.
>
> In the case of the random functions, as I said in previous
> discussions, I tend to go with a new APIs, clean, with a couple more
> algorithms as well as easy to use functions for the common usages
> (crypto safe or not). Anthony implemented something in userland, there
> are a couple of libraries available too (in C, used by python f.e.)
> providing very handy APIs. That's the way I would choose.

New APIs would be preferable. Technically, there's nothing wrong with
mt_rand() since it does what it says on the box. A mt_rand() function
that isn't predictable using a known seed is actually broken ;).
Leaking its values may have implications since the seed is vulnerable
to recovery, but it already has a bad rep for use anywhere in
security.

Anthony's library is quite good for cases where getting a decent
crypto safe random value isn't possible, but it's really something of
a last resort and the thing that makes it decent is the algorithm for
mixing entropy sources.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative