Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118302
Message-ID: <76f9b0be-85c1-5f09-3034-b4dc6f9cf22e@gmx.de>
Date: Mon, 25 Jul 2022 14:23:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: de-DE
To: Jakub Zelenka <bukka@php.net>, Go Kudo <zeriyoshi@gmail.com>
Cc: =?UTF-8?Q?Tim_D=c3=bcsterhus?= <tim@bastelstu.be>,
 PHP internals <internals@lists.php.net>
References: <CABTDVhC4J8WuKj4SdVK6hbZX2k7qrPDVCQ2g1Yb_4k4Hf5MEQQ@mail.gmail.com>
 <aa395f78-aebe-d52c-a419-aa0effeb64df@bastelstu.be>
 <CABTDVhDC6K37N6E_wJxzyrqSX2RsPL-OryW6BOOApUD2W_e94Q@mail.gmail.com>
 <CAEKnhAF4XsF6y98roSGtCmFn7K+cak2hXDYsbk8KVuqXXEwtOQ@mail.gmail.com>
In-Reply-To: <CAEKnhAF4XsF6y98roSGtCmFn7K+cak2hXDYsbk8KVuqXXEwtOQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] What do you think CSPRNG in PHP
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 25.07.2022 at 13:32, Jakub Zelenka wrote:

> On Mon, Jul 25, 2022 at 12:14 PM Go Kudo <zeriyoshi@gmail.com> wrote:
>
>> 2022=E5=B9=B47=E6=9C=8817=E6=97=A5(=E6=97=A5) 6:33 Tim D=C3=BCsterhus <=
tim@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 insecur=
e)
>>> 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 templa=
te
>>> 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 th=
e
>>> vast majority of users.
>>>
>>> Personally I likely wouldn't have merged the PR in question for the sa=
me
>>> 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.

=2D-
Christoph M. Becker