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

> On 3 Oct 2025, at 01:16, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

Adding Joe to the thread since he usually have insights into all things FIPS.

> ..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.

Well, with the IANAL disclaimer in place I tried to research this.  FIPS 140-2
implementation guidance [0] lists example scenarios where non-approved
algorithms are allowed, and while this usecase would not fit into this the
additional comments section has this:

    "1) the algorithm is not used whatsoever to meet any FIPS 140-2
    requirements; 2) the algorithm does not access or share CSPs in a way
    that counters the requirements of this IG; 3) the algorithm is either:
    i) not intended to be used as a security function (e.g.
    interoperability or for memory wear leveling); ii) redundant to an
    approved algorithm (e.g.  double encryption); iii) a cryptographic or
    mathematical operation applied for “good measure” but not for providing
    sound security (e.g.  XORing a CSP with a secret value, using a
    proprietary algorithm, or using non-approved algorithms to obfuscate
    stored CSPs which are considered plaintext); 4) the algorithm’s
    non-approved use and purpose (from 3) above) is unambiguous to the
    operator and can’t be easily confused for a security function.

 FIPS 140-3 implementation guidance [1] discuss non-approved algorithms in
 processing without security claims and include this wording:

    "..if it is clear that the purpose of a service does not include
    providing any security functionality recognized in FIPS 140-3 then the
    service can use non-approved algorithms in the approved mode if
    provisions of this IG are met."

While the IG documents are intended for development of software which will
undergo FIPS certification, which is different from this discussion, they give
interesting clues (and there are no NIST publications which cover what we
discuss here).

With the above in mind I think "maybe" is the best answer here (or "it depends"
which probably fit this equally well).  If UUID generation can be considered to
not provide any security functionality then a non-FIPS validated RNG (FIPS
140-2 Annex C [2] talks more about RNGs) can likely be used.  Any app which use
a UUID in any way which can be considered a security functionality would
however not be able to do that.  If anyone is able to find official NIST
documentation which can shed more light on this then that would be great.

I guess this is a long-winded way of saying that if we provide pg_fast_random
then users must be able to shortcuircit it with pg_strong_random() along the
lines of the below pseudocode (like how pgcrypto.builtin_crypto_enabled gives
similar non-FIPS avoidance guarantees to pgcrypto).

bool
pg_fast_random(void *buf, size_t len)
{
    if (must_use_strong_random)
        return pg_strong_random(buf, len);
    ...
}

This would need to be properly documented of course.  Maybe we should even
start a dedicated subsection on FIPS in the manual to collect information for
anyone wanting to use PostgreSQL in a FIPS compliant environment?  (That would
be for another thread though, to keep the goalposts in sight here.)

--
Daniel Gustafsson

[0]
https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf
[1]
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
[2] https://csrc.nist.rip/publications/fips/fips140-2/fips1402annexc.pdf