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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
