Re: Support getrandom() for pg_strong_random() source

On Tue, Sep 30, 2025 at 12:44 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 30 Sep 2025, at 00:15, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)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.

Sounds reasonable. But I have one question: in systems that must be
FIPS compliant, is it okay to generate UUIDs using random numbers from
non-FIPS compliant sources? If yes, we can use
pg_random/pg_fast_random() for UUID generation in all cases.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com