Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118271
Message-ID: <aa395f78-aebe-d52c-a419-aa0effeb64df@bastelstu.be>
Date: Sat, 16 Jul 2022 23:33:42 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Go Kudo <zeriyoshi@gmail.com>, PHP internals <internals@lists.php.net>
References: <CABTDVhC4J8WuKj4SdVK6hbZX2k7qrPDVCQ2g1Yb_4k4Hf5MEQQ@mail.gmail.com>
In-Reply-To: <CABTDVhC4J8WuKj4SdVK6hbZX2k7qrPDVCQ2g1Yb_4k4Hf5MEQQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] What do you think CSPRNG in PHP
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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