Hacker News Reader

Comment by zaarn | Hacker News Reader

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG.

Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves.

But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

View on HN

When the device blocks, the application can always do a non-blocking read to determine if data is available.

Why doesn't the device simply block until it has collected sufficient randomness?

Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted.

The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.

It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.

> It's better to deadlock than to revert to a weak RNG

..for you. Other people have a different threat model where availability is ranked above RNG strength in the first minute of booting. Making security decisions not based on any sort of threat model considerations is zealotry/cargo-culting, IMO.

The kernel doesn't do that.

Above all else, the rule is that the kernel shouldn't cause userspace regressions. Something that works now must continue working later.

Or how about it blocks, and then if the user starts rambling on the keyboard, it collects entropy?

Right, that would be fine. I think. The point is it's gotta break in a way that requires attention. In the IOT setting often no user input easily available. The OS should not lie to the apps when it hands them numbers that are supposed to be crypto random.

/dev/random kinda does but a lot of applications also rely on /dev/urandom which doesn't, which is why it's a problem to some extend.

Atleast from what I know.

I don't understand why it's not possible to make /dev/random block until there is enough entropy in the pool for the seed, and never block afterwards when it can securely do key-stretching.

After seeding, there is no point in blocking on a lack of entropy, which is why it is recommended to use /dev/urandom in the first place.

This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described.

So getrandom(2) will block until the pool is seeded, and all newly written application should use it, and existing applications should switch to it. But you still need to try to lazily generated random keys, and think very hard about whether you really need to generate cryptographic grade random numbers before the user logs in.

Is there a way to review the different paths and come up with answers for all of them?

E.g., if on a platform with a hardware RNG then it should never be necessary to block: just read 128 bits out of the hardware RNG & generate a stream of random numbers.

On a platform without a hardware RNG, could one require a previous seed? An installer could install the seed in some persistent storage somewhere, so there's no need to do this even on boot. A VM system needs someway to atomically read the seed & then write a new seed.

On a platform without a hardware RNG and without a previous seed (i.e., the very first boot after a hand-install or something), could the system require the user to type keys until it has collected 128 bits of entropy?

I'm not certain if there's a good answer on systems with no hardware RNG, no previous seed and no input capability. Maybe CPU timing loops or somesuch?

It'd be also be nice were there a filesystem interface to getrandom(2) …

How do you decide whether or not you trust the hardware RNG? Do you trust RDRAND? Some people do, other people are convinced it may be backdoored by Intel at the request of the NSA. Worst of all, there is no way to tell which belief is true. So there are potential real problems with hardware RNG's if you are worried about state sponsored attackers who are willing to intercept hardware shipments.

Requiring a previous seed requires a way to get access to the seed, early enough in the boot that it is available to kernel users who are trying to use randomness for address space randomization and for stack canaries. But in early boot the kernel may not be sufficiently initialized to read from persistent storage, and there are many, many bootloaders.

The reason why there is no file system interface to getrandom(2) is that a file system interface is subject to file descriptor exhaustion attacks. It was OpenBSD which designed the getentropy(2) system call, and getrandom(2) was modelled after it. Basically, getrandom(2) is getentropy(2) with an extra flags parameter added.

> I'm not certain if there's a good answer on systems with no hardware RNG, no previous seed and no input capability.

Typically, the crypto is needed for network communication. It can provide some randomness too...

Some discussion:

https://lists.freedesktop.org/archives/systemd-devel/2018-Ma...

I think a perverse sense of ABI stability, in this case. Don't want to change expectations for any userspace program, ever. getrandom(2) theoretically provides the actually useful behavior.

What makes you think that that's impossible? It's what the BSDs do.

Reply on news.ycombinator.com