From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Support getrandom() for pg_strong_random() source |
Date: | 2025-07-30 19:58:00 |
Message-ID: | 675a70ab-9657-4bd6-876f-b8d01f8e24b7@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.07.25 18:13, Jacob Champion wrote:
> On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut<peter(at)eisentraut(dot)org> wrote:
>> The POSIX description of getentropy() says:
>>
>> "The intended use of this function is to create a seed for other
>> pseudo-random number generators."
>>
>> So using getentropy() for generating the random numbers that are passed
>> back to the application code would appear to be the wrong use.
> What are the situations in which a stream of numbers would be suitable
> for seeding a CSPRNG, but not suitable as output from a CSPRNG?
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.
I mean, they called it "get entropy", not "get random", for a reason?
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-07-30 20:04:14 | Re: pg_dump --with-* options |
Previous Message | Andrei Lepikhov | 2025-07-30 19:22:44 | Re: track generic and custom plans in pg_stat_statements |