| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: OpenSSL randomness seeding |
| Date: | 2020-08-02 07:05:03 |
| Message-ID: | 20200802070503.GH3317@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2020-08-02 08:57:41 | Re: problem with RETURNING and update row movement |
| Previous Message | Noah Misch | 2020-08-02 06:48:23 | Re: OpenSSL randomness seeding |