Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118300
MIME-Version: 1.0
References: <CABTDVhC4J8WuKj4SdVK6hbZX2k7qrPDVCQ2g1Yb_4k4Hf5MEQQ@mail.gmail.com>
 <aa395f78-aebe-d52c-a419-aa0effeb64df@bastelstu.be> <CABTDVhDC6K37N6E_wJxzyrqSX2RsPL-OryW6BOOApUD2W_e94Q@mail.gmail.com>
In-Reply-To: <CABTDVhDC6K37N6E_wJxzyrqSX2RsPL-OryW6BOOApUD2W_e94Q@mail.gmail.com>
Date: Mon, 25 Jul 2022 12:32:39 +0100
Message-ID: <CAEKnhAF4XsF6y98roSGtCmFn7K+cak2hXDYsbk8KVuqXXEwtOQ@mail.gmail.com>
To: Go Kudo <zeriyoshi@gmail.com>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000398e2d05e49f8b5e"
Subject: Re: [PHP-DEV] What do you think CSPRNG in PHP
From: bukka@php.net (Jakub Zelenka)

--000000000000398e2d05e49f8b5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <ti=
m@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 templat=
e
> > 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 sam=
e
> > 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 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

--000000000000398e2d05e49f8b5e--