Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F485C1.4010208@cubiclesoft.com>
References: <52F485C1.4010208@cubiclesoft.com>
Date: Fri, 7 Feb 2014 08:11:01 +0100
Message-ID: <CAEZPtU4PvW3BBF3175kBitQCOhAZoO23rHeDUKuQ7wMv7oDb+A@mail.gmail.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Make mcrypt_create_iv() an alias and move the code into /ext/standard
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Feb 7, 2014 at 8:05 AM, Thomas Hruska <thruska@cubiclesoft.com> wrote:
> mcrypt_create_iv() is the cleanest access to a universal system-level
> primitive that supports both /dev/urandom and php_win32_get_random_bytes()
> under the hood.  Unfortunately, it resides in /ext/mcrypt and the mcrypt
> extension isn't always enabled/available (nor should it be).  At any rate,
> it is quite odd that the function php_win32_get_random_bytes() is compiled
> into the core of PHP by default under Windows but there's currently no way
> to get at it except through an extension.  There's good code in
> mcrypt_create_iv() that is significantly useful outside of the rest of that
> extension and it isn't actually dependent upon libmcrypt for proper
> operation.
>
> Moving the guts of this non-dependent function into the core would allow
> mcrypt_create_iv() to just become an alias.  The new userland function could
> be located in /ext/standard/rand.c and have an uncreative name like
> rand_bytes().

We do not force to enable extension with external dependencies, even
less in ext/standard.

However, if any function should be enabled by default, if the deps are
available obviously, it should be the one from openssl, it is by far
more available and better.

Also we need something to differentiate crypto safe vs strong entropy
sources to avoid the usual issues with crypto safe used in cases with
no requirements for crypto safe entropy.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org