Uniting the Linux random-number devices [LWN.net]

Uniting the Linux random-number devices

Posted Feb 28, 2022 4:06 UTC (Mon) by nybble41 (subscriber, #55106)
In reply to: Uniting the Linux random-number devices by koh
Parent article: Uniting the Linux random-number devices

> before I could assume that /dev/random gives to me whatever the hardware generates

That has not been the case in any version of /dev/random in Linux since the feature was first implemented as a mix of sources of hardware entropy based on secure hashes in 1994. The notable differences since then are (a) using better mixing functions, (b) adding more sources of entropy, and (c) no longer limiting the amount of data read (after initialization) based on a flawed interpretation of entropy.

If you want "raw" random data from hardware then you want /dev/hwrng, not /dev/random.

to post comments

Uniting the Linux random-number devices

Posted Feb 28, 2022 22:57 UTC (Mon) by koh (subscriber, #101482) [Link] (2 responses)

So exactly when do I want /dev/random in contrast to /dev/urandom?

Uniting the Linux random-number devices

Posted Feb 28, 2022 23:17 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Now? When it disappearing would break a userspace program you don't want to (or lack the means to) recompile.

Uniting the Linux random-number devices

Posted Mar 1, 2022 11:07 UTC (Tue) by neggles (subscriber, #153254) [Link]

Under the current behaviour, /dev/random will block if the CSPRNG has not yet been fully seeded, and /dev/urandom will not. For 99.9% of use cases in userspace there's no functional difference between the two; by the time your program is running, the CSPRNG will almost certainly be fully seeded. on a systemd system it definitely will be.

systemd and other initsystems are just about the only place where the distinction between "blocks until fully seeded" and "gives you the best numbers it can even if they suck" - as Lennart mentioned here, systemd uses the non-blocking source during early boot to seed some hash tables; the quality of that randomness is not important since they'll be reseeded later if collisions occur, but it can't carry on with boot until it's got something to work with.

In other words, the distinction only really matters if you're writing an initsystem.