Re: Support getrandom() for pg_strong_random() source

Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:

> On Fri, Oct 3, 2025 at 5:11 AM Joe Conway <mail(at)joeconway(dot)com> wrote:
>> That RFC appears to be specific to UUIDv4, but assuming that advice is generally
>> applicable to UUIDs in general it seems to mean we are off the hook when it
>> comes to FIPS with respect to UUIDs.
>
> The most recent RFC still says that [1]. And it doesn't appear to
> mandate the use of a CSPRNG at all, so it'd be unfortunate if UUIDs
> were bound by FIPS considerations... but my opinion has no effect on
> whether they're bound in practice.

It doesn't mandate (MUST) a CSPRNG, but it strongly recommends (SHOULD)
it (unless unavailable) in the best practices section
(https://www.rfc-editor.org/rfc/rfc9562.html#name-unguessability)

6.9. Unguessability

Implementations SHOULD utilize a cryptographically secure
pseudorandom number generator (CSPRNG) to provide values that are
both difficult to predict ("unguessable") and have a low likelihood
of collision ("unique"). The exception is when a suitable CSPRNG is
unavailable in the execution environment. Take care to ensure the
CSPRNG state is properly reseeded upon state changes, such as
process forks, to ensure proper CSPRNG operation. CSPRNG ensures the
best of Sections 6.7 and 8 are present in modern UUIDs.

- ilmari

> --Jacob
>
> [1] https://www.rfc-editor.org/rfc/rfc9562.html#name-security-considerations