On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski <aa...@icicle.io> wrote: > >> On Jul 14, 2015, at 4:04 PM, Sammy Kaye Powers <m...@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> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
