Uniting the Linux random-number devices

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

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.