Re: Core functions throwing exceptions in PHP7

On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski <aaron@icicle.io> wrote: > >> On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers <me@sammyk.me> 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>