On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski <[email protected]> wrote:
>
>> On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers <[email protected]> wrote:
>>
>> Hello lovely PHP nerds,
>>
>> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
>>
>> https://github.com/php/php-src/pull/1397 (main
>> discussion)
>> https://github.com/php/php-src/pull/1398
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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. :)
>>
>> Thanks,
>> Sammy Kaye Powers
>> sammyk.me
>>
>> 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=1). 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
I must have overlooked a detail here.
According to https://github.com/tpunt/PHP7-Reference#throwable-interface
there are Throwables called Error, as a separate designation from an
exception. I didn't see this in the engine exceptions RFC, so I was
unaware that was even a thing.
In this case, yes, as long as you can wrap it in try/catch blocks,
SecurityError which extends Error and/or implements Throwable is an
excellent suggestion.
Previously, I thought the suggestion was to stick to triggering errors
(E_ERROR, E_RECOVERABLE_ERROR, etc.).
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>