Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uniting the Linux random-number devices

lwn.net

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Uniting the Linux random-number devices

#41

Post by jcranmer »

throway_zwudbo wrote: post #38
zx2c4 wrote: post #19

I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!

This is probably way outside of my sphere of competence, but.... If your approach is adopted, people would simply treat /dev/random and /dev/urandom as the same thing (which I gather is your intended goal). That is fine as long as CSPRNGs are relatively easy to make. I hear that this hinges on fancy theorems like P=BPP being true, but apparently they're not proven yet. What if... in some parallel universe it turns ou…

You're already misunderstanding how /dev/random and /dev/urandom work today, or indeed ever worked. Both devices have always read from the output of a CSPRNG.

It used to be that /dev/random did some accounting to try to estimate how much entropy was in its pool, and if that number declined too low (as reading from /dev/random was figured to decrease the entropy), it would simply refuse to run its CSPRNG to produce any more output until it get fed some more entropy. This accounting was heavily criticized for being magic thinking and unsupported by any actual research, and revisions to the randomness engine in Linux over the past decade have eventually eliminated this entropy accounting in favor of just tracking how much has ever been added--if there's not enough, then it blocks until there is.

Re: Uniting the Linux random-number devices

#42

Post by vlovich123 »

zx2c4 wrote: post #31
stingraycharles wrote: post #27

Earlier quoted context omitted.

Seems like a no-brainer to me; as I understand, this effectively make urandom “always secure”, which is a very good thing; makes for an even more convincing argument when some colleague insists on using /dev/random “because it’s more secure”. Do I understand correctly that with this patch, the only drawback is for weird architectures that do not have an instruction counter or another instruction to gather random data…

Right, it unifies /dev/urandom, /dev/random, and getrandom(flags=0) to all do exactly the same thing. Most modern userspaces already use getrandom(flags=0). Nothing changes for them. They already count on the rng being seeded in one way or another. Rather, this changes /dev/urandom, which previously would give insecure randomness before being seeded. With this change, this doesn't happen any more, because it makes /d…

Wasn't there many cases where they tried to make /dev/urandom wait until entropy & it broke many distros on certain machines? What's different this time around?

Re: Uniting the Linux random-number devices

#43

Post by jcranmer »

vlovich123 wrote: post #42
zx2c4 wrote: post #31

Earlier quoted context omitted.

Right, it unifies /dev/urandom, /dev/random, and getrandom(flags=0) to all do exactly the same thing. Most modern userspaces already use getrandom(flags=0). Nothing changes for them. They already count on the rng being seeded in one way or another. Rather, this changes /dev/urandom, which previously would give insecure randomness before being seeded. With this change, this doesn't happen any more, because it makes /d…

Wasn't there many cases where they tried to make /dev/urandom wait until entropy & it broke many distros on certain machines? What's different this time around?

I believe that was fixed by the last-ditch Linus Jitter Dance.

Re: Uniting the Linux random-number devices

#44

Post by westurner »

https://en.wikipedia.org/wiki//dev/random#Linux has :

> In October 2016, with the release of Linux kernel version 4.8, the kernel's /dev/urandom was switched over to a ChaCha20-based cryptographic pseudorandom number generator (CPRNG) implementation [16] by Theodore Ts'o, based on Bernstein's well-regarded stream cipher ChaCha20.

> In 2020, the Linux kernel version 5.6 /dev/random only blocks when the CPRNG hasn't initialized. Once initialized, /dev/random and /dev/urandom behave the same. [17]

Re: Uniting the Linux random-number devices

#45

Post by daneel_w »

loeg wrote: post #29
daneel_w wrote: post #18

Earlier quoted context omitted.

Nor can OpenBSD. The system doesn't crash if /etc/random.seed isn't writable.

OpenBSD's non-blocking design, as you've described it, isn't secure if that file isn't writeable. The security of the design assumes that file is writeable. It may not crash, but instead it "fails open."

I'd rather put it this way: much of the design's security relies on the file being unique, which it is for every installation. The file can only be read and written by the superuser, and if you have superuser access (or access to the host hardware) and can leak or meddle with the file, the host is already entirely compromised.

Re: Uniting the Linux random-number devices

#46

Post by lixtra »

jcranmer wrote: post #43
vlovich123 wrote: post #42

Earlier quoted context omitted.

Wasn't there many cases where they tried to make /dev/urandom wait until entropy & it broke many distros on certain machines? What's different this time around?

I believe that was fixed by the last-ditch Linus Jitter Dance.

Since I wanted to learn more about Linus Jitter Dance, here is the patch: https://github.com/torvalds/linux/commit/50ee7529ec45

And here is discussion of the concept: https://news.ycombinator.com/item?id=9512718

Re: Uniting the Linux random-number devices

#47

Post by Denvercoder9 »

daneel_w wrote: post #45
loeg wrote: post #29

Earlier quoted context omitted.

OpenBSD's non-blocking design, as you've described it, isn't secure if that file isn't writeable. The security of the design assumes that file is writeable. It may not crash, but instead it "fails open."

I'd rather put it this way: much of the design's security relies on the file being unique , which it is for every installation. The file can only be read and written by the superuser, and if you have superuser access (or access to the host hardware) and can leak or meddle with the file, the host is already entirely compromised.

Requiring a unique file for every installation is not always feasible. Consider e.g. embedded devices or VMs that run from prebuilt images.

There have been too many examples of seed files being reused, it's time to recognize that requiring a unique seed file is not good property for an RNG to have.

Re: Uniting the Linux random-number devices

#48

Post by kroeckx »

I'm still not really convinced about how much entropy is collected by the jitter entropy technique. I've been looking at https://github.com/smuellerDD/jitterentropy-library previously, which is for instance used by OpenWRT. It's hard to do a proper estimation of the entropy, because depending on how you measure it, you get different results. The library has been changed, but it's probably still overestimating the entropy.

Re: Uniting the Linux random-number devices

#49

Post by daneel_w »

Denvercoder9 wrote: post #47
daneel_w wrote: post #45

Earlier quoted context omitted.

I'd rather put it this way: much of the design's security relies on the file being unique , which it is for every installation. The file can only be read and written by the superuser, and if you have superuser access (or access to the host hardware) and can leak or meddle with the file, the host is already entirely compromised.

Requiring a unique file for every installation is not always feasible. Consider e.g. embedded devices or VMs that run from prebuilt images. There have been too many examples of seed files being reused, it's time to recognize that requiring a unique seed file is not good property for an RNG to have.

Such setups should always be prepared so that they run their "firstboot", not just for this case but also for e.g. generating unique sshd keys etc. This is how "Linux in the cloud" is treated, and I really don't see why anyone would think differently for OpenBSD. In OpenBSD's case the seed file is also rendered anew by rc on each boot. If you believe you have a substantial case against their design I urge you to bring it up on their mailing lists, as everyone would benefit from the insight and the improvements.

Re: Uniting the Linux random-number devices

#50

Post by Panino »

Denvercoder9 wrote: post #47
daneel_w wrote: post #45

Earlier quoted context omitted.

I'd rather put it this way: much of the design's security relies on the file being unique , which it is for every installation. The file can only be read and written by the superuser, and if you have superuser access (or access to the host hardware) and can leak or meddle with the file, the host is already entirely compromised.

Requiring a unique file for every installation is not always feasible. Consider e.g. embedded devices or VMs that run from prebuilt images. There have been too many examples of seed files being reused, it's time to recognize that requiring a unique seed file is not good property for an RNG to have.

OpenBSD has two seed files but random number generation isn't limited to them. OpenBSD has more random sources (such as from jitter) than other systems and regularly reseeds itself. Both seed files are re-written multiple times during the boot process, each time incorporating new random. So by the time sshd starts for the very first time and creates host keys (like ssh-keygen -A), those keys should have access to good random.

The first file, /etc/random.seed is 512 bytes and is available very early as it's on the root filesystem. This file is re-written by rc(8) at every boot, halt, shutdown, and reboot.

Second, /var/db/host.random is 65536 bytes. It is also re-written by rc at every boot, halt, shutdown and reboot.

In addition to all that, rc includes:

  # If bootblocks failed to give us random, try to cause some churn
  (dmesg; sysctl hw.{uuid,serialno,sensors} ) >/dev/random 2>&1
I just checked my VMs and they all print unique values for dmesg, hw.uuid and hw.serialno. I can guess but I don't know how hw.uuid and hw.serialno are set.
Post reply on HN