Re: Support getrandom() for pg_strong_random() source

On Tue, Aug 26, 2025 at 12:42 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 26 Aug 2025, at 00:38, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> >
> > On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >>
> >> For instance, we could
> >> introduce a GUC parameter that lets users specify their preferred
> >> random number source. Or the server can automatically select it based
> >> on the kernel's FIPS mode (i.e., checking
> >> /proc/sys/crypto/fips_enabled).
> >
> > Interesting idea. (Are there any users reading along who would
> > definitely use such a feature?)
>
> I worry about the added complexity this would bring. It's already quite
> complicated to configure postgres, and making an informed decision about which
> RNG source to choose for cryptographically strong random won't be easy without
> domain knowledge.
>
> Taking a step back and re-reading the thread, this started as a proposal to
> improve uuid generation on non-Windows platforms when not using OpenSSL. While
> non-SSL installations will be incredibly rare in production, it will likely be
> a bit more common in PG development situations and speeding up test-runs in
> such situations has value. I think this thread has shown merit to the idea of
> replacing using /dev/urandom with a more modern API, but after sleeping on it
> I'm less convinced that a'la carte CSPRNG configuration has enough upsides to
> warrant the risk of users accidentally becoming non-FIPS compliant.

The primary motivation is to enhance the performance of random data
generation and UUID creation in scenarios where FIPS compliance is not
mandatory. As I previously reported[1], getrandom() demonstrates
superior performance for small random data operations, with the
efficiency gain becoming even more significant in newer kernels thanks
to the vDSO implementation of getrandom() (note that I assume
cryptographic equivalence between random data generated by
RAND_bytes() in non-FIPS mode and that produced by getrandom()).

Although this would introduce additional configuration complexity, I
guess that FIPS-compliant random data is unnecessary for most users,
and getrandom()'s output is typically sufficient for many
implementations. I think while maintaining RAND_bytes() as the default
option for OpenSSL-enabled installations, we could somehow provide
users with the flexibility to opt for getrandom() when preferred.

>
> Another related thing to consider, uuid-ossp contrib module use arc4random() in
> the non e2fs case.

An alternative approach for users seeking to generate UUIDs via
getrandom() would be to utilize UUIDv7 through uuid_generate_time_v7()
provided by libuuid in e2fs cases. Since this method internally
leverages getrandom(), it should benefit from vDSO execution
capabilities. However, we need to note that UUIDv7 values generated
through uuid_generate_time_v7() exhibit several distinctions from
those produced by PostgreSQL's implementation.

Regards,

[1] https://www.postgresql.org/message-id/CAD21AoD1%2B6FwGb0d4W3YEwOVJi_McuyuvpnjUJE8B8Ejy21MMw%40mail.gmail.com

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