> On 30 Sep 2025, at 00:15, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
> I'm wary of letting unprivileged users switch this implementation. I
> think our developers should be allowed to treat the user as an
> adversary when developing features on top of pg_strong_random(), and
> it doesn't make sense for an adversary to control properties of your
> CSPRNG.
Agreed.
> I'm also worried that allowing users to change the FIPS
> properties of their systems could lead to compliance headaches for
> some DBAs,
Very much so. It might not move the needle in practice, but the fact that it
could be changed will inevitably lead to a feature request to be able to
disable it.
I think we're trying to fit two square pegs in the same not-square hole here.
While none of the pegs want poor entropy, one (for example UUID generation)
favours speed over CSPRNG properties where the other couldn't care less about
speed if any CSPRNG properties are even looked at the wrong way on a bad day.
What if we instead expand the API to provide pg_random (or pg_fast_random)
which can be a selectable implementation, and pg_strong_random is left as today
a compile time selection? This would allow extension authors and built-in *non
security/auth* features which need to squeeze all the performance they can out
of the API to use an alternative implementation while leaving pg_strong_random
to give CSPRNG guarantees to code that need it.
--
Daniel Gustafsson
