Threads for kees

    1. 2
      inactive-user avatar inactive-user edited 4 years ago | link | on: SSH takes minutes to become available, booting half an hour... because your server waits for entropy

      Lets see how this can turn out on a raspberry pi (version: 1, model: B, Raspbian Buster):

      root@rpi:/# dmesg | grep -E "(rng|random)"
[    0.000000] random: get_random_bytes called from start_kernel+0x8c/0x49c with crng_init=0
[    0.374000] bcm2835-rng 20104000.rng: hwrng registered
[    2.107462] random: fast init done
[    7.005858] random: systemd: uninitialized urandom read (16 bytes read)
[    7.072358] random: systemd: uninitialized urandom read (16 bytes read)
[    7.101514] random: systemd: uninitialized urandom read (16 bytes read)
[   35.634711] random: crng init done
[   35.634733] random: 7 urandom warning(s) missed due to ratelimiting

      Yikes! 35 seconds! Even with hwrng! This could have easily been much worse!

      So what did we learn from this?

      • It can take up to 1h40m before your linux-server in a virtual machine comes up. It can take tens of minutes before your non-virtual linux server boots up.
      • If you want a quick and permanent, but flawed fix, you have to enable RDRAND (of which we can reasonably assume that it has been compromised).
      • If this happens to you on server machines, spend the 50$ for a chaoskey (or some other similar entropy source) for every server to be done with this failure mode once and for all (If the number of servers you run is small enough for this to be feasible, that is).
      • Forward the host entropy pool to the guests and/or any containers.
      • If you’re in a pinch and find yourself in front of a machine that doesn’t come up:
        • If you can afford it: just stoically wait it out for at most 2 hours.
        • If you need the machine to boot up quickly, connect a mouse or keyboard and make some random moves or hit some random keys.

      This is a fine mess….

      1. 1
        bityard avatar bityard 4 years ago | link | on: SSH takes minutes to become available, booting half an hour... because your server waits for entropy

        If you want a quick and permanent, but flawed fix, you have to enable RDRAND (of which we can reasonably assume that it has been compromised).

        If you don’t trust the random number generator in your CPU, what is the basis upon which you decide to trust the rest of the CPU?

        If this happens to you on server machines, spend the 50$ for a chaoskey

        What makes the STM32F042 microcontroller more trustworthy as a source of entropy than the CPU? Is it open hardware? With a third-party auditable manufacturing process?

        1. 1
          inactive-user avatar inactive-user 4 years ago | link | on: SSH takes minutes to become available, booting half an hour... because your server waits for entropy

          If you don’t trust the random number generator in your CPU, what is the basis upon which you decide to trust the rest of the CPU?

          It’s not about trust in the CPU. It’s about having trust in what has been used to encrypt data that leaves the CPU.

          What makes the STM32F042 microcontroller more trustworthy as a source of entropy than the CPU? Is it open hardware? With a third-party auditable manufacturing process?

          The fact that the attached circuit is a sensible source for thermal noise and the fact that I can verify that.

        2. 1
          kees avatar kees 4 years ago | link | on: SSH takes minutes to become available, booting half an hour... because your server waits for entropy

          On a v4.19 or newer kernel, make sure you either built with CONFIG_RANDOM_TRUST_CPU=y or booted with “random.trust_cpu=on” to jump-start the pRNG.

          And if you want even more entropy, get one of these: https://altusmetrum.org/ChaosKey/