Re: Support getrandom() for pg_strong_random() source

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Michael Paquier <michael@paquier.xyz>, Daniel Gustafsson <daniel@yesql.se>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-30T21:03:53Z
Lists: pgsql-hackers
On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> I imagine a "get entropy" operation could be very slow or even blocking,
> whereas a random number generator might just have to do some arithmetic
> starting from the previous seed state.

Agreed -- it could absolutely be slower, but if it's not slower in
practice in a user's environment, is there a problem with using it as
the basis for pg_strong_random()? That doesn't seem "wrong" to me; it
just seems like a tradeoff that would take investigation.

(The "blocking" fear is related to the research I linked above -- we
don't really want our CSPRNG to block in the way that /dev/random used
to, because that's not helpful. But we absolutely want it to block if
the CSPRNG state hasn't initialized yet. The goal continues to be
strength over performance IMO -- but there is circumstantial evidence
here that getentropy() could maybe get us both, in some environments.)

--Jacob