On 25.07.2022 at 13:32, Jakub Zelenka wrote: > On Mon, Jul 25, 2022 at 12:14 PM Go Kudo <zeriyo...@gmail.com> wrote: > >> 2022年7月17日(日) 6:33 Tim Düsterhus <t...@bastelstu.be>: >> >>> On 7/15/22 17:54, Go Kudo wrote: >>>> However, there are several challenges to this. >>>> >>>> - Increased maintenance costs >>>> - Requires optimization for CPU architecture >>>> - Requires familiarity with CSPRNG >>>> >>>> PHP already bundles xxHash and appears ready to make this happen. >>>> >>>> Also, an appropriate CSPRNG implementation may be able to resolve the >>>> current complex macro branching. >>>> >>>> What do you think about this? >>> >>> This would be a strong no from my side. There's all types of failure >>> modes that decrease the security of the CSPRNG (i.e. making it insecure) >>> and we really don't want to be the ones to blame if something goes >>> wrong. And historically many non-kernel CSPRNGs later proved to be >>> insecure in specific situations. >>> >>> I also would assume that for a typical PHP application both of the >>> following is true: >>> - The majority of the requests don't need any randomness. >>> - The majority of the requests that *need* randomness don't need any >>> significant amount of randomness. >>> - The majority of the requests that need significant amounts of >>> randomness are fine with a regular PRNG (e.g. Xoshiro or Pcg). >>> - The cost of a few getrandom() syscalls is not really measurable >>> compared to the time spent waiting for the database, file IO or template >>> rendering. >>> >>> Attempting to optimize the speed of the CSPRNG is premature >>> optimization. That also the reason why I suggested to use the 'Secure' >>> engine by default in the Randomizer: It's a safe default choice for the >>> vast majority of users. >>> >>> Personally I likely wouldn't have merged the PR in question for the same >>> reasons. But at least in that case glibc is at fault :-) >> >> You are right. Implementing a CSPRNG on your own obviously increases >> maintenance costs and security risks. >> >> However, I still think the overhead of the getrandom syscall in a Linux >> environment is significant and should be considered. > > There is already a good CSPRNG available in OpenSSL which we expose > with openssl_random_pseudo_bytes (except on Windows which is historical and > should change)
TIL! Yes, that should change. > so for those that are impacted by the syscall overhead, this > might be the best option considering that most users are using at least > OpenSSL version 1.1.1 where the new CSPRNG is available. We cannot, however, rely on any OpenSSL functionality in the core or ext/standard, since OpenSSL *might* not be available. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
