Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
Date: Thu, 23 Jul 2015 12:26:31 -0500
Cc: scott@paragonie.com,
 Yasuo Ohgaki <yohgaki@ohgaki.net>,
 rowan.collins@gmail.com,
 pierre.php@gmail.com,
 brian@moonspot.net,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
To: Sammy Kaye Powers <me@sammyk.me>
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: aaron@icicle.io (Aaron Piotrowski)


> On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers <me@sammyk.me> wrote:
>=20
> Hello lovely PHP nerds,
>=20
> There are two open PR's for PHP7 to modify the behavior of the =
CSPRNG's:
>=20
> https://github.com/php/php-src/pull/1397 (main discussion)
> https://github.com/php/php-src/pull/1398
>=20
> Currently the random_*() functions will issue a warning and return =
false if
> a good source of random cannot be found. This is a potential security =
hole
> in the event the RNG fails and returns false which gets evaluated as 0 =
in a
> cryptographic context.
>=20
> To prevent this exploit the proposed behavior will throw an Exception =
when
> the RNG fails or certain argument validation fails. This also gives =
the
> developer a graceful way to fall back to an alternate CSPRNG.
>=20
> Since the core functions in PHP don't throw Exceptions, there is =
debate on
> whether or not this change should be implemented. Some say the =
CSPRNG's
> should get a special pass since they will be relied on for =
cryptography. If
> we can't throw Exceptions, there were suggestions of raising a fatal =
error
> if the RNG fails.
>=20
> I think the argument can be boiled down to consistency vs security. =
We'd
> love to hear your feedback to decide what we should do in this =
context. :)
>=20
> Thanks,
> Sammy Kaye Powers
> sammyk.me
>=20
> Chicago, IL 60604

How about instead of throwing an instance of Exception, the random_*() =
functions throw an instance of Error on failure. A subclass of Error, =
such as SecurityError could also be added. As it is unlikely that the =
failure of these functions to generate a random value could be handled =
at runtime, throwing an instance of Error makes the most sense imho.

Many internal functions can result in an instance of Error being thrown, =
particularly with declare(strict_types=3D1). So those looking for =
consistency can be satisfied that other internal functions already can =
behave similarly, and those looking to fail closed can be satisfied that =
an exception will be thrown if securely generating a random value fails.

Aaron Piotrowski=