From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OpenSSL randomness seeding |
Date: | 2020-08-02 21:24:56 |
Message-ID: | 1E7B66B6-62B7-4698-9AE4-D5E0139E735E@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 2 Aug 2020, at 09:05, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-08-02 21:30:21 | Re: MultiXact\SLRU buffers configuration |
Previous Message | Tom Lane | 2020-08-02 21:18:05 | Re: Fix for configure error in 9.5/9.6 on macOS 11.0 Big Sur |