7 ms·

Is it cryptographically possible to not require randomness for an SSH server past initial key creation? If so it'd be worth doing, quality entropy is a hard ask

Is it cryptographically possible to not require randomness for an SSH server past initial key creation? If so it'd be worth doing, quality entropy is a hard ask for embedded/virtual systems.

pstrateman 7y ago
No sshd needs to generate nonces and session keys.
mehrdadn 7y ago
Yeah, I don't understand what's so cryptographically special about booting. If the system hadn't been turned off and on, it wouldn't have had a problem, right? Sounds like the real problem is some part of the system can't be bothered to persist its state. Either that, or the problem should also come up during normal usage, in which case there's a security hole somewhere.
- pstrateman 7y ago
  systemd isn't using the right interface for adding the entropy in the seed file, so the kernel uses it but counts it as zero bits of entropy edit: but i guess that's on purpose to handle disk imaging
  - mehrdadn 7y ago
    Yeah I was just reading that. Why was that not an obvious bug to be fixed immediately? I haven't read much of the GitHub issues but it seems so weird to recommend trusting the CPU RNG instead of just pushing out a quick fix...
    - raverbashing 7y ago
      > Why was that not an obvious bug to be fixed immediately? Welcome to SystemD
    - Hello71 7y ago
      because people are poorly educated and copy their system disks without changing the random seed. then, they generate similar long-term keys, e.g. RSA keys with common factors. digitalocean was well known to have identical SSH host keys for quite some time (one of many reasons I wouldn't trust them with any sort of remotely serious hosting job); I would be shocked if they knew to reset the random seed.
      - throw0101a 7y ago
        > because people are poorly educated and copy their system disks without changing the random seed. To a first approximation: * SHA256( cat /var/lib/randomseed || ifconfig || date -u ) > /dev/urandom will get any decent stream-cipher-based PRNG going. Each machine will have a unique MAC address, so that's 48 bits right off the bat, even if randomseed is identical and every machine is booted at the exact same second.
        Hello71 7y ago
        I strongly suspect that this information is already included in the Linux kernel RNG, but it is not given much weight in the entropy calculation, on the basis that virtualized systems frequently have duplicated MAC addresses (as is allowed on a non-public system), and sometimes also have low initial timestamp resolution.
        throw0101a 7y ago
        If a system will be communicating with other systems, it will need a unique Layer 2 address. This can be leveraged for some entropy (certainly you don't have to credit the full 48 bits, but are you tell saying that not even 1-2 bits of credit cannot be applied?). If the system is not communicating with other systems... what attack tree are you actually worried about if it is inaccessible? I would also be curious to know which virtualization environments generate duplicate MAC addresses over (say) dozens of systems?
        Hello71 7y ago
- deleted 7y ago
  [deleted]
- zajio1am 7y ago
  > Sounds like the real problem is some part of the system can't be bothered to persist its state. Persistent state is hard. For example, some systems run with read-only filesystem.
  - mehrdadn 7y ago
    I thought about that, but then, if you setup that kind of a system, isn't it your responsibility to worry about how to generate and persist cryptographic state? It's such a niche and advanced use-case by someone who should really know better considering the setup... why should all the other >95% of users pay such a price for it? Edit: Replaced "host keys" with "cryptographic state".
    - zajio1am 7y ago
      The issue is not about host keys, which are generated once. It is about randomness that sshd needs for nonces and session keys. It needs fresh randomness during each boot.
      - mehrdadn 7y ago
        Okay, I substituted "cryptographic state" for "host keys". It doesn't change my argument.
buildzr 7y ago
For virtual systems it shouldn't be, Virtio has an RNG provider that's able to use host entropy: https://fedoraproject.org/wiki/Features/Virtio_RNG https://fedoraproject.org/wiki/Features/Virtio_RNG For embedded systems, many have inbuilt RNGs, have a look at your SoC docs.
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.
howard941 7y ago
Very hard ask for small embedded devices. Maybe you can get part of the way there mixing the low order bit(s) of a number of somewhat noisy floating ADC inputs? Against a half hearted nearby attacker I'm not sure I'd bank on it though.
sneak 7y ago
The real question is why can’t sshd do this after forking? Read and parse the config, fork, and lazily build an entropy pool. Let the ssh connections or key generations hang if there isn’t enough entropy yet, but don’t get in the way of booting. This is two bugs: one in systemd, and one in OpenSSH.

Is it cryptographically possible to not require randomness for an SSH server past initial key creation? If so it'd be worth doing, quality entropy is a hard ask for embedded/virtual systems.

pstrateman 7y ago

No sshd needs to generate nonces and session keys.

mehrdadn 7y ago

Yeah, I don't understand what's so cryptographically special about booting. If the system hadn't been turned off and on, it wouldn't have had a problem, right? Sounds like the real problem is some part of the system can't be bothered to persist its state. Either that, or the problem should also come up during normal usage, in which case there's a security hole somewhere.

pstrateman 7y ago
systemd isn't using the right interface for adding the entropy in the seed file, so the kernel uses it but counts it as zero bits of entropy edit: but i guess that's on purpose to handle disk imaging
- mehrdadn 7y ago
  Yeah I was just reading that. Why was that not an obvious bug to be fixed immediately? I haven't read much of the GitHub issues but it seems so weird to recommend trusting the CPU RNG instead of just pushing out a quick fix...
  - raverbashing 7y ago
    > Why was that not an obvious bug to be fixed immediately? Welcome to SystemD
  - Hello71 7y ago
    because people are poorly educated and copy their system disks without changing the random seed. then, they generate similar long-term keys, e.g. RSA keys with common factors. digitalocean was well known to have identical SSH host keys for quite some time (one of many reasons I wouldn't trust them with any sort of remotely serious hosting job); I would be shocked if they knew to reset the random seed.
    - throw0101a 7y ago
      > because people are poorly educated and copy their system disks without changing the random seed. To a first approximation: * SHA256( cat /var/lib/randomseed || ifconfig || date -u ) > /dev/urandom will get any decent stream-cipher-based PRNG going. Each machine will have a unique MAC address, so that's 48 bits right off the bat, even if randomseed is identical and every machine is booted at the exact same second.
      - Hello71 7y ago
        I strongly suspect that this information is already included in the Linux kernel RNG, but it is not given much weight in the entropy calculation, on the basis that virtualized systems frequently have duplicated MAC addresses (as is allowed on a non-public system), and sometimes also have low initial timestamp resolution.
        throw0101a 7y ago
        If a system will be communicating with other systems, it will need a unique Layer 2 address. This can be leveraged for some entropy (certainly you don't have to credit the full 48 bits, but are you tell saying that not even 1-2 bits of credit cannot be applied?). If the system is not communicating with other systems... what attack tree are you actually worried about if it is inaccessible? I would also be curious to know which virtualization environments generate duplicate MAC addresses over (say) dozens of systems?
        Hello71 7y ago
deleted 7y ago
[deleted]
zajio1am 7y ago
> Sounds like the real problem is some part of the system can't be bothered to persist its state. Persistent state is hard. For example, some systems run with read-only filesystem.
- mehrdadn 7y ago
  I thought about that, but then, if you setup that kind of a system, isn't it your responsibility to worry about how to generate and persist cryptographic state? It's such a niche and advanced use-case by someone who should really know better considering the setup... why should all the other >95% of users pay such a price for it? Edit: Replaced "host keys" with "cryptographic state".
  - zajio1am 7y ago
    The issue is not about host keys, which are generated once. It is about randomness that sshd needs for nonces and session keys. It needs fresh randomness during each boot.
    - mehrdadn 7y ago
      Okay, I substituted "cryptographic state" for "host keys". It doesn't change my argument.

buildzr 7y ago

For virtual systems it shouldn't be, Virtio has an RNG provider that's able to use host entropy: https://fedoraproject.org/wiki/Features/Virtio_RNG https://fedoraproject.org/wiki/Features/Virtio_RNG For embedded systems, many have inbuilt RNGs, have a look at your SoC docs.

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.

howard941 7y ago

Very hard ask for small embedded devices. Maybe you can get part of the way there mixing the low order bit(s) of a number of somewhat noisy floating ADC inputs? Against a half hearted nearby attacker I'm not sure I'd bank on it though.

sneak 7y ago

The real question is why can’t sshd do this after forking? Read and parse the config, fork, and lazily build an entropy pool. Let the ssh connections or key generations hang if there isn’t enough entropy yet, but don’t get in the way of booting. This is two bugs: one in systemd, and one in OpenSSH.