Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers

Jacob Champion <jacob.champion@enterprisedb.com> writes:

> On Fri, Oct 3, 2025 at 5:11 AM Joe Conway <mail@joeconway.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