Re: OpenSSL randomness seeding

David Steele <david@pgmasters.net>

From: David Steele <david@pgmasters.net>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-21T20:00:42Z
Lists: pgsql-hackers
On 7/21/20 3:44 PM, Daniel Gustafsson wrote:
>> On 21 Jul 2020, at 17:31, David Steele <david@pgmasters.net> wrote:
>> On 7/21/20 8:13 AM, Daniel Gustafsson wrote:
> 
>>> Another thing that stood out when reviewing this code is that we optimize for
>>> RAND_poll failing in pg_strong_random, when we already have RAND_status
>>> checking for a sufficiently seeded RNG for us.  ISTM that we can simplify the
>>> code by letting RAND_status do the work as per 0002, and also (while unlikely)
>>> survive any transient failures in RAND_poll by allowing all the retries we've
>>> defined for the loop.
>>
>> I wonder how effective the retries are going to be if they happen immediately. However, most of the code paths I followed ended in a hard error when pg_strong_random() failed so it may not hurt to try. I just worry that some caller is depending on a faster failure here.
> 
> There is that, but I'm not convinced that relying on specific timing for
> anything RNG or similarly cryptographic-related is especially sane.

I wasn't thinking specific timing -- just that the caller might be 
expecting it to give up quickly if it doesn't work. That's what the code 
is trying to do and I wonder if there is a reason for it.

But you are probably correct and I'm just overthinking it.

Regards,
-- 
-David
david@pgmasters.net



Commits

  1. Remove optimization for RAND_poll() failing.

  2. Use RAND_poll() for seeding randomness after fork().