On Tue, Aug 26, 2025 at 12:42 AM Daniel Gustafsson wrote:
>
> > On 26 Aug 2025, at 00:38, Jacob Champion
> > wrote:
> >
> > On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada
> > wrote:
> >>
> >> For instance, we could
> >> introduce a GUC parameter that lets users specify their preferred
> >> ra
> On 26 Aug 2025, at 00:38, Jacob Champion
> wrote:
>
> On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada wrote:
>>
>> For instance, we could
>> introduce a GUC parameter that lets users specify their preferred
>> random number source. Or the server can automatically select it based
>> on the ke
On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada wrote:
>
> For instance, we could
> introduce a GUC parameter that lets users specify their preferred
> random number source. Or the server can automatically select it based
> on the kernel's FIPS mode (i.e., checking
> /proc/sys/crypto/fips_enabled)
On Mon, Aug 25, 2025 at 1:07 PM Jacob Champion
wrote:
>
> On Mon, Aug 25, 2025 at 11:30 AM Masahiko Sawada
> wrote:
> > > Gathering a couple of considerations from upthread:
> > > - FIPS behavior
> >
> > Do you mean random numbers generated by getrandom() complaints FIPS?
> > Based on my researc
On Mon, Aug 25, 2025 at 11:30 AM Masahiko Sawada wrote:
> > Gathering a couple of considerations from upthread:
> > - FIPS behavior
>
> Do you mean random numbers generated by getrandom() complaints FIPS?
> Based on my research, there doesn't appear to be any explicit
> statement indicating that L
On Mon, Aug 18, 2025 at 8:38 AM Jacob Champion
wrote:
>
> On Thu, Aug 14, 2025 at 3:16 PM Masahiko Sawada wrote:
> >
> > On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion
> > wrote:
> >
> > > So, my next question: is getrandom() always preferable to /dev/urandom?
> >
> > I believe so. While /dev/ura
On Mon, Aug 18, 2025 at 4:17 PM Michael Paquier wrote:
>
> On Mon, Aug 18, 2025 at 08:38:25AM -0700, Jacob Champion wrote:
> > - Need for safety in virtualized environments
> > - ...?
>
> Interesting. What do you mean by this point? Isolation of the
> random computations on a VM/container basis
On Mon, Aug 18, 2025 at 08:38:25AM -0700, Jacob Champion wrote:
> - Need for safety in virtualized environments
> - ...?
Interesting. What do you mean by this point? Isolation of the
random computations on a VM/container basis even if these are
originally from the same host?
--
Michael
signatu
On Thu, Aug 14, 2025 at 3:16 PM Masahiko Sawada wrote:
>
> On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion
> wrote:
>
> > So, my next question: is getrandom() always preferable to /dev/urandom?
>
> I believe so. While /dev/urandom source should be kept as a fallback
> for older kernels, we should u
On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion
wrote:
>
> On Fri, Aug 8, 2025 at 3:25 PM Masahiko Sawada wrote:
> > On the other hand, I found a blog post[3] (10 years-old post) that on
> > Solaris the output of getentropy() should not be used where randomness
> > is needed. I'm not sure it's stil
On Tue, Jul 29, 2025 at 9:38 AM Dagfinn Ilmari Mannsåker
wrote:
>
> Jacob Champion writes:
>
> > On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
> >
> >> Could getentropy() be more efficient at the end on most platforms,
> >> meaning that this could limit the meaning of having a GUC switc
On Fri, Aug 8, 2025 at 3:25 PM Masahiko Sawada wrote:
> On the other hand, I found a blog post[3] (10 years-old post) that on
> Solaris the output of getentropy() should not be used where randomness
> is needed. I'm not sure it's still true but I guess that it might be
> reasonable to consider tha
On Wed, Jul 30, 2025 at 2:04 PM Jacob Champion
wrote:
>
> On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut
> 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 prev
On Wed, Jul 30, 2025 at 02:03:53PM -0700, Jacob Champion wrote:
> On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut
> 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 t
On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut 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
On 30.07.25 18:13, Jacob Champion wrote:
On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut 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 number
On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut 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 a
On 30.07.25 13:55, Daniel Gustafsson wrote:
The point still stands that the number of installations without OpenSSL support
is approximately zero, so what is the purpose of this patch if approximately no
one will be able to use it?
The main usecase I've heard discussed (mostly in hallway tra
Dagfinn Ilmari Mannsåker writes:
> Masahiko Sawada writes:
>
>> On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion
>> wrote:
>>>
>>> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
>>> > My understanding of the problem is that it is a choice of efficiency
>>> > vs entropy, and that it's not
> On 30 Jul 2025, at 13:10, Peter Eisentraut wrote:
>
> On 30.07.25 08:59, Masahiko Sawada wrote:
>> I've updated the patch to support getentropy() instead of getrandom().
>
> The point still stands that the number of installations without OpenSSL
> support is approximately zero, so what is the
Masahiko Sawada writes:
> On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion
> wrote:
>>
>> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
>> > My understanding of the problem is that it is a choice of efficiency
>> > vs entropy, and that it's not really possible to have both parts of
>> >
On 30.07.25 08:59, Masahiko Sawada wrote:
I've updated the patch to support getentropy() instead of getrandom().
The point still stands that the number of installations without OpenSSL
support is approximately zero, so what is the purpose of this patch if
approximately no one will be able to
On 22.07.25 13:11, Dagfinn Ilmari Mannsåker wrote:
getrandom() is Linux-specific, while getentropy() is specified by POSIX
(since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
2017, musl 1.1.20 and FreeBSD 12
On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion
wrote:
>
> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
> > My understanding of the problem is that it is a choice of efficiency
> > vs entropy, and that it's not really possible to have both parts of
> > the cake.
Agreed. I think the opti
Jacob Champion writes:
> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
>
>> Could getentropy() be more efficient at the end on most platforms,
>> meaning that this could limit the meaning of having a GUC switch?
>
> I don't know. [2] implies that the performance comparison depends on
>
On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
> My understanding of the problem is that it is a choice of efficiency
> vs entropy, and that it's not really possible to have both parts of
> the cake.
That was my understanding too, but then [1] called that into question.
If -- and I don't
On Mon, Jul 28, 2025 at 06:14:20PM +0200, Daniel Gustafsson wrote:
> On 28 Jul 2025, at 17:29, Jacob Champion
> wrote:
>> To move this forward a tiny bit: I would be okay with maintaining a
>> new getentropy() case. (I'm less excited about getrandom() because of
>> its reduced reach.) And maybe d
> On 28 Jul 2025, at 17:29, Jacob Champion
> wrote:
> To move this forward a tiny bit: I would be okay with maintaining a
> new getentropy() case. (I'm less excited about getrandom() because of
> its reduced reach.) And maybe down the line we should discuss choosing
> an option at configure time
On Mon, Jul 28, 2025 at 4:36 AM Daniel Gustafsson wrote:
> There has in the past been discussions (at least off-list in hallway tracks)
> about allowing randomness to be chosen separately from underlying factors such
> as OpenSSL support, at the time it didn't seem worth the trouble but that may
>
> On 23 Jul 2025, at 19:11, Jacob Champion
> wrote:
> .. maybe the pendulum has swung far enough that we can expect any
> kernel supporting getentropy() to be able to do the job just as well
> as OpenSSL does in userspace, except also faster? I think it might be
> worth a discussion.
There has
On Tue, Jul 22, 2025 at 4:23 PM Masahiko Sawada wrote:
> The trend of the results were similar:
>
> getrandom: 497.061 ms
> RAND_bytes: 1152.260 ms ms
> /dev/urandom: 1696.065 ms
>
> Please let me know if I'm missing configurations or settings to
> measure this workload properly.
I don't think yo
On Tue, Jul 22, 2025 at 11:46 AM Jacob Champion
wrote:
>
> On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada
> wrote:
> > While getentropy() has better portability, according to the
> > getentropy() manual, the maximum length is limited to 256 bytes. It
> > works in some cases such as generating
umbers as well, but only through the use of the
pgcrypto extension, which makes gen_random_bytes available. Pulling pgcrypto
into ...
brandur.org
Thanks
Regards
Dinesh Nair
From: Masahiko Sawada
Sent: Wednesday, July 23, 2025 12:02 AM
To: Dagfinn Ilmari Ma
On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada wrote:
> While getentropy() has better portability, according to the
> getentropy() manual, the maximum length is limited to 256 bytes. It
> works in some cases such as generating UUID data but seems not
> appropriate for our general pg_strong_rando
On Tue, Jul 22, 2025 at 4:12 AM Dagfinn Ilmari Mannsåker
wrote:
>
> Masahiko Sawada writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier
> > wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new so
Masahiko Sawada writes:
> On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier wrote:
>>
>> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
>> > The patch supports the getrandom() function as a new source of
>> > pg_strong_random(). The getrandom() function uses the same source as
>
On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier wrote:
>
> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> > The patch supports the getrandom() function as a new source of
> > pg_strong_random(). The getrandom() function uses the same source as
> > the /dev/urandom device but i
On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> The patch supports the getrandom() function as a new source of
> pg_strong_random(). The getrandom() function uses the same source as
> the /dev/urandom device but it seems much faster than opening,
> reading, and closing /dev/urand
Hi all,
Currently we have three options for pg_strong_random() sources:
1. OpenSSL's RAND_bytes()
2. Windows' CryptGenRandom() function
3. /dev/urandom
The patch supports the getrandom() function as a new source of
pg_strong_random(). The getrandom() function uses the same source as
the /dev/ura
39 matches
Mail list logo
