On Wed, Aug 27, 2025 at 4:48 PM Masahiko Sawada <[email protected]> wrote: > > On Tue, Aug 26, 2025 at 12:42 AM Daniel Gustafsson <[email protected]> wrote: > > > > > On 26 Aug 2025, at 00:38, Jacob Champion > > > <[email protected]> wrote: > > > > > > On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada <[email protected]> > > > 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.
I've drafted this idea and attached two patches. The first patch
allows the user to select the random source function used in the
backend. 'openssl' is the default value if PostgreSQL is built with
openssl but users can set it to 'system' use the '/dev/urandom/'
approach (or CryptGenRandom on Windows) instead if they want. In
frontend code, there is nothing changed; the actual implementation of
pg_strong_random is chosed at build time and openssl's RAND_bytes() is
always used if the source code is built with openssl. Therefore, it
doesn't break any existing use cases but provides a way to select the
random source function.The second patch adds support for getrandom()
as the default random source of 'system' random source type on
Unix-like platforms.
With these two patches, for example, users can set random_source_type
to 'system' in the configuration file or a connection string in order
to use getrandom() for random data generation for UUID generation even
on openssl-enabled builds:
% echo "show random_source_type; select uuidv7();" | bin/psql -d
"dbname=postgres port=5432 options='-c random_source_type=openssl'" -X
random_source_type
--------------------
openssl
(1 row)
uuidv7
--------------------------------------
01997599-b6b6-7590-9825-f36253059956
(1 row)
% echo "show random_source_type; select uuidv7();" | bin/psql -d
"dbname=postgres port=5432 options='-c random_source_type=system'" -X
random_source_type
--------------------
system
(1 row)
uuidv7
--------------------------------------
01997599-f069-76b6-9ce2-0308d0cd6a0b
(1 row)
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
0001-PoC-Select-random-source-type.patch
Description: Binary data
0002-PoC-Support-getrandom-as-the-source-of-pg_strong_ran.patch
Description: Binary data
