Re: Support getrandom() for pg_strong_random() source

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?

In response to

Responses

Browse pgsql-hackers by date

  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