3 ms·

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

by tytso 8y ago

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.

masterleep 8y ago
Some discussion: https://lists.freedesktop.org/archives/systemd-devel/2018-May/040685.html https://lists.freedesktop.org/archives/systemd-devel/2018-Ma...
zeveb 8y ago
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) …
- tytso 8y ago
  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.
- acqq 8y ago
  > 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...

by tytso 8y ago

masterleep 8y ago

Some discussion: https://lists.freedesktop.org/archives/systemd-devel/2018-May/040685.html https://lists.freedesktop.org/archives/systemd-devel/2018-Ma...

zeveb 8y ago

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) …

tytso 8y ago
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.
acqq 8y ago
> 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...