[Denvercoder9]

Requiring a unique file for every installation is not always feasible. Consider e.g. embedded devices or VMs that run from prebuilt images.

There have been too many examples of seed files being reused, it's time to recognize that requiring a unique seed file is not good property for an RNG to have.

[Panino]

OpenBSD has two seed files but random number generation isn't limited to them. OpenBSD has more random sources (such as from jitter) than other systems and regularly reseeds itself. Both seed files are re-written multiple times during the boot process, each time incorporating new random. So by the time sshd starts for the very first time and creates host keys (like ssh-keygen -A), those keys should have access to good random.

The first file, /etc/random.seed is 512 bytes and is available very early as it's on the root filesystem. This file is re-written by rc(8) at every boot, halt, shutdown, and reboot.

Second, /var/db/host.random is 65536 bytes. It is also re-written by rc at every boot, halt, shutdown and reboot.

In addition to all that, rc includes:

  # If bootblocks failed to give us random, try to cause some churn
  (dmesg; sysctl hw.{uuid,serialno,sensors} ) >/dev/random 2>&1

I just checked my VMs and they all print unique values for dmesg, hw.uuid and hw.serialno. I can guess but I don't know how hw.uuid and hw.serialno are set.

[daneel_w]

Such setups should always be prepared so that they run their "firstboot", not just for this case but also for e.g. generating unique sshd keys etc. This is how "Linux in the cloud" is treated, and I really don't see why anyone would think differently for OpenBSD. In OpenBSD's case the seed file is also rendered anew by rc on each boot. If you believe you have a substantial case against their design I urge you to bring it up on their mailing lists, as everyone would benefit from the insight and the improvements.