Hacker News Reader

Comment by daneel_w | Hacker News Reader

OpenBSD solved this problem long ago. Is the reason behind Linux' hesitancy/opposition to their solution of technical or philosophical nature?

View on HN

Linux is used in many more contexts than OpenBSD. Moreover, unlike OpenBSD, Linux explicitly promises not to break userspace on new releases. So yeah, the Linux devs are more hesitant about anything that might be a user-visible behavior change.

OpenBSD never removed /dev/random - though they did remove arandom and prandom. But I'm not sure how your response explains the reasons for why they avoided OpenBSD's solution.

OpenBSD behaves like this patch, the article does a good job of describing what it has taken on the Linux side to get to this point and why IMO. In particular it wasn't until recently there was a reliable way to get quick randomness on nearly any machine to avoid blocking for long periods on boot which things had come to expect avoiding in the previous implementation.

How did they solve it?

The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block.

Add.: the seed file is unique per installation, and is also updated continously by the system.

Seed files are useful, but not a perfect solution, because they can be snapshotted or cloned in a virtual machine context, or otherwise shared/leaked. Also, they require a device to have writeable memory, which again does not work in all contexts.

I don't think trying to spin this as "OpenBSD solved this years ago" is especially helpful. OpenBSD has made a different set of design tradeoffs than the Linux authors, and both are arguably reasonable designs.

I don't understand what you mean by "trying to spin this", or how that, whatever it means, is not helpful. Helpful towards what? Admittedly I don't know if there has been a successful effort that breaks or otherwise proves OpenBSD's non-blocking solution as insecure, but I'd be glad to read any conclusions if you have any to share - it's why I asked about the reasons behind Linux developers' objection to the solution.

Linux keeps track of "credit" for entrophy pool sources.

Anyone can write to /dev/random - this mixes data into the entrophy pool but it won't be "credited" as securely increasing /proc/sys/kernel/random/entropy_avail . https://www.whonix.org/wiki/Dev/Entropy

Similarly, systemd-boot can seed from disk but will not "credit" entrophy. https://systemd.io/RANDOM_SEEDS/

If the point of /dev/random is to provide crytographically secure random numbers, then some level of paranoia is needed for determining which sources are "credited" for initializing the pool. https://lwn.net/Articles/760121/

On OpenBSD only root can write to urandom, but anyone can provide entropy through for example disk i/o and keyboard input. I might be wrong, but I suspect the rationale is that if someone has root access to your system, you have plenty more to worry about besides the entropy pool.

E.g. Linux can't assume that the system has a writable disk.

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.

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.

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.

But what if it wasn't writeable recently but has been in the past? How do you know that the seed data isn't stale and you are starting up the entropy pool in exactly the same state as last time, and the time before that, and ...

In some security contexts this could be a significant concern.

The seed file will go stale if you deny the system to update it. It's the first source for the entropy pool, but it's not the only source. I really have no idea how large effect the random subsystem suffers as a whole if that source is allowed to go stale.

How do you know somebody hasn't hex edited the kernel to nop out the rng entirely?

You usually don't, unless you demand signed kernels and have a secure method of blocking unsigned ones.

But the read-only filesystem issue is something that could happen by accident rather than malicious alteration - for instance some filesystem errors may result in it being mounted RO for safety until the corruption is addressed.

I had heard that the concern was that there are services very early in boot that rely on /dev/urandom never blocking. I’m not sure how true that is, or why it is no longer a concern now.

Reply on news.ycombinator.com