4 ms·

> The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. It feeds the entropy pool, mixed in wi

> The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. It feeds the entropy pool, mixed in with many sources. OpenBSD also feeds in data from the AMD CCP as well. The point is it doesn't matter. https://man.openbsd.org/ccp https://man.openbsd.org/ccp And anyone running "echo badapples > /dev/random" in a loop, it still doesn't matter. https://man.openbsd.org/random.4 https://man.openbsd.org/random.4 https://man.openbsd.org/arc4random.9 https://man.openbsd.org/arc4random.9 > How does OpenBSD guarantee that this file exists, though? If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. If the random.seed file is not available (for example, boot media), it is not fatal. There is a warning displayed. But the system rc(8) scripts handle creating the seed file at both boot and shutdown. https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...

deathanatos 7y ago
> If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Assuming you haven't got a HW generator at hand, what other source are there that don't take significant time to collect from? (I.e., I know you can get it from network timings, keyboard/mouse if they exist, etc., but that takes time, and would cause a call not wanting to return prior to there being sufficient data to block. If you're only mixing in unready or untrusted sources, you might get lucky and make it hard for an attacker, or worse, if your other sources are blocking b/c they're collecting data… you might not, but regardless it hardly seems principled?) It'd be willing to write off the first boot, except that I feel like a lot of things do potentially get initialized then; e.g., in a VM in the cloud, I think that's when host keys are initialized, for example, and certainly whatever application that VM might be hosting could have further requirements. Not blocking and issuing a warning would be to supply data prior to having sufficiently initialized a generator, no?
- ori_b 7y ago
  > Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install. Take a look at https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub https://github.com/openbsd/src/blob/master/distrib/miniroot/..., specifically, feed_random and store_random
  - deathanatos 7y ago
    Okay, that's fair for install media installing to a physical machine such as a desktop. What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Also, there's the case posed in response to my first comment, about IOT devices which would ship with some factory-installed image. (I suppose there are some novel ways one could work around this such as somehow keeping a pool of one-shot images ready w/ just the seed added to them, but I don't feel like this is how real-world systems work. E.g., an AMI in AWS?)
    - aquabeagle 7y ago
      http://man.openbsd.org/man4/viornd.4 http://man.openbsd.org/man4/viornd.4
    - wbl 7y ago
      HW rng is essential then
    - ori_b 7y ago
      > What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Mitigations within mitigations. Having one random seed per VM image that gets installed is better than having nothing at all -- now, an attacker needs to have your install image. Then the hardware RNG and the virtio random drivers help mix into that seed. Given that presumably you've already booted the image for testing, you've probably already generated the SSH keys that you need to be concerned about -- so you'd probably need to take care to regenerate them securely in any case, from a running system that has started to gather entropy from all the sources it can get its hands on, including the boot loader. And, ideally part of the imaging process would write some random data to the image. But I agree, most people wouldn't even think of doing that.

deathanatos 7y ago

> If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Assuming you haven't got a HW generator at hand, what other source are there that don't take significant time to collect from? (I.e., I know you can get it from network timings, keyboard/mouse if they exist, etc., but that takes time, and would cause a call not wanting to return prior to there being sufficient data to block. If you're only mixing in unready or untrusted sources, you might get lucky and make it hard for an attacker, or worse, if your other sources are blocking b/c they're collecting data… you might not, but regardless it hardly seems principled?) It'd be willing to write off the first boot, except that I feel like a lot of things do potentially get initialized then; e.g., in a VM in the cloud, I think that's when host keys are initialized, for example, and certainly whatever application that VM might be hosting could have further requirements. Not blocking and issuing a warning would be to supply data prior to having sufficiently initialized a generator, no?

ori_b 7y ago
> Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install. Take a look at https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub https://github.com/openbsd/src/blob/master/distrib/miniroot/..., specifically, feed_random and store_random
- deathanatos 7y ago
  Okay, that's fair for install media installing to a physical machine such as a desktop. What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Also, there's the case posed in response to my first comment, about IOT devices which would ship with some factory-installed image. (I suppose there are some novel ways one could work around this such as somehow keeping a pool of one-shot images ready w/ just the seed added to them, but I don't feel like this is how real-world systems work. E.g., an AMI in AWS?)
  - aquabeagle 7y ago
    http://man.openbsd.org/man4/viornd.4 http://man.openbsd.org/man4/viornd.4
  - wbl 7y ago
    HW rng is essential then
  - ori_b 7y ago
    > What about virtual machines / machines booting off an image? We can't put a seed in the image, or it'll get distributed to all downstream consumers. Mitigations within mitigations. Having one random seed per VM image that gets installed is better than having nothing at all -- now, an attacker needs to have your install image. Then the hardware RNG and the virtio random drivers help mix into that seed. Given that presumably you've already booted the image for testing, you've probably already generated the SSH keys that you need to be concerned about -- so you'd probably need to take care to regenerate them securely in any case, from a running system that has started to gather entropy from all the sources it can get its hands on, including the boot loader. And, ideally part of the imaging process would write some random data to the image. But I agree, most people wouldn't even think of doing that.