3 ms·

> A system only needs 16-32 bytes of pure hardware randomness for strong security. That's it! Correct. > You either have it shortly upon boot, or you don't.

> A system only needs 16-32 bytes of pure hardware randomness for strong security. That's it! Correct. > You either have it shortly upon boot, or you don't. Not correct. On virtualized systems, with minimal interrupts, there is frequently not enough entropy available. This comment seems to reflect a poor understanding of the getrandom(2) system call and its history; part of the reason for implementing getrandom was in order to provide this new behavior of no longer blocking once enough entropy has been collected for a secure CSPRNG initialization. Linux needs this "entropy accounting mumbo jumbo" because it doesn't have a standard mechanism for persisting random seeds across boots; OpenBSD doesn't need it because the bootloader and kernel are tightly integrated, so they can easily implement this feature.

wahern 7y ago
virtio-rng has been around since 2013. If a hypervisor doesn't support passing through entropy, then it's broken. Period. Entropy accounting can't fix the underling problems here, all they do is obscure and confuse. Hypothetically and in a very technical sense, they can be useful and even necessary. But in practice they simply have no place outside of the actual hardware-based entropy generating devices. If you can't quickly seed yourself with 32[1] bytes of cryptographically strong entropy, then you're screwed, period. Blocking doesn't improve security, it just induces people and developers to implement awkward workarounds with the net effect of drastically reducing security. When Linux added the getrandom syscall they should have dropped support for blocking. It was patterned after OpenBSD getentropy, which doesn't block; neither did Linux' long deprecated sysctl() random UUID mechanism that many programs once relied upon (like Tor). But they, and Ts'o in particular, seem unable to resist the siren call of entropy guesstimation. [1] Even 16 bytes is enough to seed the system pool for an indefinite period, at least relative to a system without a strong hardware RNG. And that's the point. There are reasons for why a component might need ongoing sources of strong entropy, but if a system can't even provide 16-32 bytes at boot then those arguments are purely hypothetical because there clearly aren't sources of strong entropy available, anyhow. But if those sources are available, then it's ridiculous to think they can be "depleted" as a practical matter. If the CSPRNG pooling functions are broken, then all modern cryptography is broken, so you gain nothing with the convoluted semantics of Linux's traditional /dev/random machinations.

wahern 7y ago

virtio-rng has been around since 2013. If a hypervisor doesn't support passing through entropy, then it's broken. Period. Entropy accounting can't fix the underling problems here, all they do is obscure and confuse. Hypothetically and in a very technical sense, they can be useful and even necessary. But in practice they simply have no place outside of the actual hardware-based entropy generating devices. If you can't quickly seed yourself with 32[1] bytes of cryptographically strong entropy, then you're screwed, period. Blocking doesn't improve security, it just induces people and developers to implement awkward workarounds with the net effect of drastically reducing security. When Linux added the getrandom syscall they should have dropped support for blocking. It was patterned after OpenBSD getentropy, which doesn't block; neither did Linux' long deprecated sysctl() random UUID mechanism that many programs once relied upon (like Tor). But they, and Ts'o in particular, seem unable to resist the siren call of entropy guesstimation. [1] Even 16 bytes is enough to seed the system pool for an indefinite period, at least relative to a system without a strong hardware RNG. And that's the point. There are reasons for why a component might need ongoing sources of strong entropy, but if a system can't even provide 16-32 bytes at boot then those arguments are purely hypothetical because there clearly aren't sources of strong entropy available, anyhow. But if those sources are available, then it's ridiculous to think they can be "depleted" as a practical matter. If the CSPRNG pooling functions are broken, then all modern cryptography is broken, so you gain nothing with the convoluted semantics of Linux's traditional /dev/random machinations.