On Mon, Aug 18, 2025 at 8:38 AM Jacob Champion <[email protected]> wrote: > > On Thu, Aug 14, 2025 at 3:16 PM Masahiko Sawada <[email protected]> wrote: > > > > On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion > > <[email protected]> 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 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]. > > Yeah. My personal reasons to be excited about it are > 1) the newer, more sensible one-shot blocking behavior for safety, and > 2) the ability for the OS to figure out when a virtualized environment > has potentially "forked" > > So I think I would be in favor of adding this as an always-preferred > alternative to /dev/urandom, to begin. > > Thinking a bit further ahead: what are some criteria we would need to > research to decide whether getrandom() would be preferable to OpenSSL? > 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 Linux's CSPRNG module complies with FIPS requirements. However, there is a proposal to implement LRNG[1], which would be FIPS-compliant. In systems that require FIPS compliance, it seems that random numbers generated by getrandom() (or getentropy()) are typically used as a seed for FIPS-compliant random number generators, such as OpenSSL's RAND_bytes() function. Regards, [1] https://lwn.net/Articles/877607/ -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
