Re: Support getrandom() for pg_strong_random() source
От | Masahiko Sawada |
---|---|
Тема | Re: Support getrandom() for pg_strong_random() source |
Дата | |
Msg-id | CAD21AoD6KgevUbb=xb3eobWC9eo6eHJ4a-qepq6kAUN9ufwsuw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support getrandom() for pg_strong_random() source (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: Support getrandom() for pg_strong_random() source
|
Список | pgsql-hackers |
On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Fri, Aug 8, 2025 at 3:25 PM Masahiko Sawada <sawada.mshk@gmail.com> 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 that this is correct behavior in principle, and > > that the behavior of glibc etc. is in some sense an exception. > > Thanks for finding that! Ah, FIPS: > > > More specifically the data returned by getentropy(2) has not had the required FIPS 140-2 processing for the DRBG appliedto it. > > So FIPS compliance is a case where "a stream of numbers would be > suitable for seeding a CSPRNG, but not suitable as output from a > CSPRNG". That's evidence enough for me to abandon my preference for > getentropy() (whether Solaris still does that or not). Makes sense. > > I've been looking at libsodium's randomness implementations [1]: > > > On Windows systems, the RtlGenRandom() function is used. > > On OpenBSD and Bitrig, the arc4random() function is used. > > On recent FreeBSD and Linux kernels, the getrandom system call is used. > > On other Unices, the /dev/urandom device is used. > > (Note that libsodium has some internal concept of a "safe" arc4random > implementation, which it locks to certain platforms. If an OS is still > literally using RC4 we would not want to use it.) > > 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 use getrandom() if available. For example, getrandom() can be used even in the face of file-descriptor exhaustion and lack of access to the random devices[1]. Also, it would be much faster than reading /dev/urandom as I shared the benchmark result[2]. Regards, [1] https://lwn.net/Articles/884875/ [2] https://www.postgresql.org/message-id/CAD21AoD1%2B6FwGb0d4W3YEwOVJi_McuyuvpnjUJE8B8Ejy21MMw%40mail.gmail.com -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: