Re: OpenSSL randomness seeding
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: Noah Misch <noah@leadboat.com>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-08-02T21:24:56Z
Lists: pgsql-hackers
> On 2 Aug 2020, at 09:05, Michael Paquier <michael@paquier.xyz> wrote: > > On Sat, Aug 01, 2020 at 11:48:23PM -0700, Noah Misch wrote: >> On Thu, Jul 30, 2020 at 11:42:16PM +0200, Daniel Gustafsson wrote: >>> Somewhat on topic though, 1.1.1 adds a RAND_priv_bytes function for random >>> numbers that are supposed to be private and extra protected via it's own DRBG. >>> Maybe we should use that for SCRAM salts etc in case we detect 1.1.1? >> >> Maybe. Would you have a separate pg_private_random() function, or just use >> RAND_priv_bytes() for pg_strong_random()? No pg_strong_random() caller is >> clearly disinterested in privacy; gen_random_uuid() may come closest. > > FWIW, I am not sure that we need extra level of complexity when it > comes to random number generation, so having only one API to rule them > all sounds sensible to me, particularly if we know that the API used > has more private protections. I would agree with that, especially since we might not be able to provide an equivalent implementation of a pg_private_random() function in non-OpenSSL builds. Will do a bit more reading and poking and post a patch. cheers ./daniel
Commits
-
Remove optimization for RAND_poll() failing.
- 15e441972276 14.0 landed
-
Use RAND_poll() for seeding randomness after fork().
- ce4939ff7089 14.0 landed