Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118301
MIME-Version: 1.0
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>
Date: Mon, 25 Jul 2022 21:08:17 +0900
Message-ID: <CABTDVhCmnEJCMZRLKrJA45LHnY6a1dHV0F17PSvpp20W_N0WoQ@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aab8f805e4a00a10"
Subject: Re: [PHP-DEV] What do you think CSPRNG in PHP
From: zeriyoshi@gmail.com (Go Kudo)

--000000000000aab8f805e4a00a10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B47=E6=9C=8825=E6=97=A5(=E6=9C=88) 20:32 Jakub Zelenka <bukka@ph=
p.net>:

>
>
> 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 <t=
im@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 th=
e
>> > > 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 :-)
>> >
>> > Best regards
>> > Tim D=C3=BCsterhus
>> >
>>
>> 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 a=
nd
> should change) so for those that are impacted by the syscall overhead, th=
is
> 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

--000000000000aab8f805e4a00a10--