Re: Support getrandom() for pg_strong_random() source
От | Jacob Champion |
---|---|
Тема | Re: Support getrandom() for pg_strong_random() source |
Дата | |
Msg-id | CAOYmi+nLraamk5LCc_JC=TYuDL5vwcXKmKuOhy6my9-o2oJr5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support getrandom() for pg_strong_random() source (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Support getrandom() for pg_strong_random() source
|
Список | pgsql-hackers |
On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut <peter@eisentraut.org> wrote: > I imagine a "get entropy" operation could be very slow or even blocking, > whereas a random number generator might just have to do some arithmetic > starting from the previous seed state. Agreed -- it could absolutely be slower, but if it's not slower in practice in a user's environment, is there a problem with using it as the basis for pg_strong_random()? That doesn't seem "wrong" to me; it just seems like a tradeoff that would take investigation. (The "blocking" fear is related to the research I linked above -- we don't really want our CSPRNG to block in the way that /dev/random used to, because that's not helpful. But we absolutely want it to block if the CSPRNG state hasn't initialized yet. The goal continues to be strength over performance IMO -- but there is circumstantial evidence here that getentropy() could maybe get us both, in some environments.) --Jacob
В списке pgsql-hackers по дате отправления: