LWN: Comments on "Uniting the Linux random-number devices"

Uniting the Linux random-number devices

neggles — Tue, 01 Mar 2022 11:07:27 +0000

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.

Uniting the Linux random-number devices

mpr22 — Mon, 28 Feb 2022 23:17:53 +0000

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

koh — Mon, 28 Feb 2022 22:57:17 +0000

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

Uniting the Linux random-number devices

nybble41 — Mon, 28 Feb 2022 04:06:31 +0000

> 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

koh — Sun, 27 Feb 2022 00:28:42 +0000

> 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

atnot — Tue, 22 Feb 2022 08:30:27 +0000

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

koh — Mon, 21 Feb 2022 23:40:28 +0000

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.

Uniting the nethack random-number devices

error27 — Mon, 21 Feb 2022 14:33:21 +0000

I used to use Chrysalis BBS (Dallas TX 1997). It had a bunch of games but hacking the RNG was always the real game. Good times.

Uniting the Linux random-number devices

ianmcc — Sat, 19 Feb 2022 14:37:39 +0000

Currently /dev/urandom doesn't block. This means there is a window once the machine has booted where you can draw numbers from /dev/urandom and it isn't properly seeded. /dev/random will block until it is properly seeded. Other than that, since 2020 they are equivalent, and /dev/random won't ever block after it has been seeded.

Once /dev/urandom is properly seeded (or you read from /dev/random), if you're an attacker and you draw 1 billion numbers, ... it doesn't help you because you can't crack the crypto in the PRNG. (well, if you *can*, you've made a breakthrough in crypto that will make you as famous as you'll be infamous).

In the old days (well, I think prior to 2020? So not so old), /dev/random would remove N bits of entropy from the pool for every N bits read from /dev/random, and if there isn't N bits of entropy available then it would block until there is. This was based on a misunderstanding that you need to consume entropy to generate cryptographically secure random numbers. But if you use a cryptographically secure PRNG, then you only need enough bits of entropy for the seed of the PRNG, and you can generate as many secure random bits as you like. Predicting the next number in the sequence requires determining the internal state of the PRNG, which isn't possible from examining the prior output (as long as the crypto algorithm doesn't contain any flaws). So there is an assumption that the crypto is strong and won't be broken.

Uniting the nethack random-number devices

ejr — Fri, 18 Feb 2022 17:45:18 +0000

sssshhhh... Don't spoil assigned homework.

Uniting the Linux random-number devices

derobert — Fri, 18 Feb 2022 16:58:14 +0000

That's not right. Both give you bits from a CSPRNG, they work exactly the same. It has to be that way — the entropy collected from most sources isn't fully random, so you need some process to extract the entropy from it and a CSPRNG is a good way to do that.

Originally /dev/random made some guess of when entropy was "depleted", but that didn't really make sense — one effect of a PRNG being cryptography secure is it doesn't deplete the entropy. So a while back, that was removed.

An attacker can gain no knowledge of the CSPRNG's state from its output (well, at least not without an impossible number of them, like 2^128). It doesn't matter if they have a few billion or trillion.

And Linux keeps mixing in new entropy, so the internal state changes over time.

Uniting the Linux random-number devices

Otus — Fri, 18 Feb 2022 05:59:18 +0000

No, other than initial blocking behavior they are the same already, they use the same entropy pool and the same crng algorithm. If there is not yet enough entropy one blocks while the other warns and returns possibly-not-random data.

Uniting the Linux random-number devices

developer122 — Fri, 18 Feb 2022 03:08:39 +0000

Let me get this straight:

At the moment, both /dev/random and /dev/urandom block, until they have enough entropy. However their entropy sources differ. /dev/random draws from "truly random, crpto-ready" bits that came directly from a hardware source of some kind, where as /dev/urandom draws from a PRNG that is seeded from /dev/random's hardware-backed bits.

But we don't care, because the bits that have passed through the pseudo-RNG have like 99% of the randomness of the hardware bits and are "good enough" for crypto to rely on? (even though they might be a little stale if it's been a while since the PRNG was re-seeded)

I _suppose_ that drawing from /dev/urandom right after it's been seeded the first time with bits from /dev/random might be just as good as drawing from /dev/urandom, but what's the difference in their worst case? ie. if I'm an attacker and later I draw 1 billion numbers from the PRNG before the next time it's re-seeded.

Uniting the nethack random-number devices

qys — Fri, 18 Feb 2022 01:33:20 +0000

Someone actually did a really fast ascension by manipulating its RNG. <https://pellsson.github.io/>

v1 posted

zx2c4 — Thu, 17 Feb 2022 16:33:32 +0000

Thanks for this summary. Encouraged by your read on the discussion, I wound up submitting a real v1 of the patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jaso...

Uniting the nethack random-number devices

ballombe — Thu, 17 Feb 2022 16:30:56 +0000

The irony is that nethack internal RNG is very weak so is easy to bruteforce even if the kernel RNG was perfect.
<https://nethackwiki.com/wiki/Random_number_generator>