5 ms·

You need randomness for ephemeral keys, both asymmetric and symmetric. Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or

by wahern 7y ago

You need randomness for ephemeral keys, both asymmetric and symmetric. Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or other server software. Intel has RDRAND, and even where AMD's RDRAND is broken their PSP coprocessors provide an entropy function. Similarly, NICs and other controllers also often come with RNGs. RNGs abound on modern embedded systems, actually, it's just that nobody has the full-time job of plugging them into the kernel's PRNG pool. It's not a full-time job for any OpenBSD developer, either, but they do seem to do a better job of this than on Linux; often times the only feature supported of a miscellaneous system component is the RNG. It's the APIs that are broken. getrandom shouldn't block, period. A system only needs 16-32 bytes of pure hardware randomness for strong security. That's it! You either have it shortly upon boot, or you don't. If you don't, you're screwed anyhow, so why block? If you have 32 bytes of good entropy, all the entropy accounting mumbo-jumbo is pointless. I do take issue with the author's complaint that systemd shouldn't have its own user-space PRNG. BSD systems have arc4random() as part of their libc, which is seeded from the kernel pool. This is very convenient; developers shouldn't have to think twice about calling into a PRNG for a 32-bit number, but if acquiring that requires a syscall they do think twice and often screw things up. Not to mention that Linux getrandom's default block semantics is broken by design.[1] Until glibc, musl libc, and other Linux runtimes wisen up and add arc4random, it's hard to blame projects like systemd for including their own PRNG. [1] I realize that getrandom has an option to not block, but it's only function is to cast suspicion on itself when in fact the only thing that deserves suspicion are entropy guesstimators.

throw0101a 7y ago
> Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or other server software. 128 bits is enough to feed into a stream cipher that will generate a lot of random bits: > The original version of this random number generator used the RC4 (also known as ARC4) algorithm. In OpenBSD 5.5 it was replaced with the ChaCha20 cipher, and it may be replaced again in the future as cryptographic techniques advance. * https://man.openbsd.org/arc4random.3 https://man.openbsd.org/arc4random.3 * https://security.stackexchange.com/questions/85601/ https://security.stackexchange.com/questions/85601/ Re-feed/-stir every so often so that past entropy state can't be used to compromise things in the future.
Hello71 7y ago
> 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.
pmoriarty 7y ago
"Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or other server software. Intel has RDRAND, and even where AMD's RDRAND is broken their PSP coprocessors provide an entropy function." I'm not a fan of trusting closed hardware for randomness.
- wahern 7y ago
  And? The fact of the matter is, there's no workable alternative. You either have a good source of entropy, or you don't. If you don't, people aren't going to stop using things like OpenSSH. If a box is blocked on boot that's universally considered broken and everybody will try to work around it. Fortunately in practice the situation isn't so dire. There are usually multiple hardware RNGs on a system. They may be all untrusted, but I'll trust them together before I'll ever trust the strength (and persisting correctness) of guesstimators. Ironically, entropy guesstimators are predicated on the very notion that the hardware is benign. Malicious hardware could implement subtle timing patterns in interrupts, much like what they might do for an actual RNG (e.g. use an AES encryption function to "randomize" their visible behavior). And in any event, you can still mix various system timing events into your pool without pretending you can quantitatively and reliably know their entropic contribution.
tzs 7y ago
Is it possible to have some scheme where the client can provide all the initial randomness for the connection? For example, the server could have an RSA private key, and the clients have the corresponding public key. A client could generate a full RSA block of random data, and encrypt that with the public key, and send the result to the server. The server could recover the random data and use that to initialize a CSPRNG. This CSPRNG could be user mode code running in the ssh system, and only used for randomness needed for that particular connection, so that if a client supplies poor random data it only weakens that client's connection.
cat199 7y ago
> It's not a full-time job for any OpenBSD developer, either, but they do seem to do a better job of this than on Linux; don't blame the linux kernel, we're just waiting on the dbus interface, gnome3 applet, and systemd binary + unit files before we integrate /etc/grub.conf.d/entropy.d/randomseed.d/grub-entropy-randomseed.conf and it's good buddy systemd-enable-grub-conf-d-entropy-d-randomseed-d.target into the Loobuntitis GNU/Linux Kubernetes CloudPaaSOS 2019.07.18 'doofy nerdguy' LTS Server release. OpenBSD guys are clearly antiquated and using old modes of thinking with such a simplistic and neanderthal like design of having a system wide library installed in a single location without a dynamic json configurable runtime rest api endpoint.

by wahern 7y ago

throw0101a 7y ago

> Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or other server software. 128 bits is enough to feed into a stream cipher that will generate a lot of random bits: > The original version of this random number generator used the RC4 (also known as ARC4) algorithm. In OpenBSD 5.5 it was replaced with the ChaCha20 cipher, and it may be replaced again in the future as cryptographic techniques advance. * https://man.openbsd.org/arc4random.3 https://man.openbsd.org/arc4random.3 * https://security.stackexchange.com/questions/85601/ https://security.stackexchange.com/questions/85601/ Re-feed/-stir every so often so that past entropy state can't be used to compromise things in the future.

Hello71 7y ago

> 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.

pmoriarty 7y ago

"Quality entropy isn't a hard ask, at least not for anything typically running OpenSSH or other server software. Intel has RDRAND, and even where AMD's RDRAND is broken their PSP coprocessors provide an entropy function." I'm not a fan of trusting closed hardware for randomness.

wahern 7y ago
And? The fact of the matter is, there's no workable alternative. You either have a good source of entropy, or you don't. If you don't, people aren't going to stop using things like OpenSSH. If a box is blocked on boot that's universally considered broken and everybody will try to work around it. Fortunately in practice the situation isn't so dire. There are usually multiple hardware RNGs on a system. They may be all untrusted, but I'll trust them together before I'll ever trust the strength (and persisting correctness) of guesstimators. Ironically, entropy guesstimators are predicated on the very notion that the hardware is benign. Malicious hardware could implement subtle timing patterns in interrupts, much like what they might do for an actual RNG (e.g. use an AES encryption function to "randomize" their visible behavior). And in any event, you can still mix various system timing events into your pool without pretending you can quantitatively and reliably know their entropic contribution.

tzs 7y ago

Is it possible to have some scheme where the client can provide all the initial randomness for the connection? For example, the server could have an RSA private key, and the clients have the corresponding public key. A client could generate a full RSA block of random data, and encrypt that with the public key, and send the result to the server. The server could recover the random data and use that to initialize a CSPRNG. This CSPRNG could be user mode code running in the ssh system, and only used for randomness needed for that particular connection, so that if a client supplies poor random data it only weakens that client's connection.

cat199 7y ago

> It's not a full-time job for any OpenBSD developer, either, but they do seem to do a better job of this than on Linux; don't blame the linux kernel, we're just waiting on the dbus interface, gnome3 applet, and systemd binary + unit files before we integrate /etc/grub.conf.d/entropy.d/randomseed.d/grub-entropy-randomseed.conf and it's good buddy systemd-enable-grub-conf-d-entropy-d-randomseed-d.target into the Loobuntitis GNU/Linux Kubernetes CloudPaaSOS 2019.07.18 'doofy nerdguy' LTS Server release. OpenBSD guys are clearly antiquated and using old modes of thinking with such a simplistic and neanderthal like design of having a system wide library installed in a single location without a dynamic json configurable runtime rest api endpoint.