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

Uniting the Linux random-number devices

Posted Feb 21, 2022 23:40 UTC (Mon) by koh (subscriber, #101482)
Parent article: Uniting the Linux random-number devices

Unfortunately - or fortunately - the fact that /dev/random and /dev/urandom use the same CRNG implies that /dev/random no longer behaves as the name suggests: you get crypto-strength random bits, but not random bits. It's clear that you didn't get random bits before they've been made the same, but that could've been considered a bug: preprocessing the hardware source's output may be necessary, but algorithmically modifying output and thereby decreasing entropy (necessarily) for hardware RNGs is suboptimal at best when you're after random numbers (opposed to crypto-strength random numbers).

While that change may have been motivated by practical reasons, it nonetheless means you now get a filtered view on random bits - filtered through the eyes of crypto-strength. It may easily not be what an application wants to receive. This blurring of semantics concerns me.

to post comments

Uniting the Linux random-number devices

Posted Feb 22, 2022 8:30 UTC (Tue) by atnot (guest, #124910) [Link] (5 responses)

If you have found a vulnerability in the BLAKE2 hash function that makes this distinction remotely meaningful in any way I'd encourage you to publish that research as soon as possible.

Uniting the Linux random-number devices

Posted Feb 27, 2022 0:28 UTC (Sun) by koh (subscriber, #101482) [Link] (4 responses)

> If you have found a vulnerability in the BLAKE2 hash function

well, that's cheap; of course not and it's beside the point.

> that makes this distinction remotely meaningful in any way

This is more to the point: before I could assume that /dev/random gives to me whatever the hardware generates - meaning, I can test the acquired data itself, develop and test hardware based on it and even find out when there is not enough data. I realize that the last point was meant to be fixed, but it does constitute a quite substantial shift in semantics I honestly see no reason for - if you want unlimited "randomness" go for /dev/urandom. Hiding the distinction between the two devices is a step in the wrong direction.

Uniting the Linux random-number devices

Posted Feb 28, 2022 4:06 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (3 responses)

> 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.

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.