2022年7月25日(月) 20:32 Jakub Zelenka <bu...@php.net>: > > > 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>: >> >> > Hi >> > >> > 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 :-) >> > >> > Best regards >> > Tim Düsterhus >> > >> >> Hi Tim. >> >> 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) 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. > > Regards > > Jakub >
Hi (Sorry, I sent you directly) Indeed, But ext-openssl is not always available. To use it in a ext-session, etc., it must be bundled reliably. Best Regards Go Kudo
