Re: OpenSSL randomness seeding
От | David Steele |
---|---|
Тема | Re: OpenSSL randomness seeding |
Дата | |
Msg-id | 9bd6d0db-4910-9f3a-3acc-7dd9112a71eb@pgmasters.net обсуждение исходный текст |
Ответ на | Re: OpenSSL randomness seeding (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: OpenSSL randomness seeding
|
Список | 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 followedended in a hard error when pg_strong_random() failed so it may not hurt to try. I just worry that some caller isdepending 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
В списке pgsql-hackers по дате отправления: