Security Recommendations for Anything That Depends on Randomly-Generated Numbers

In general, it is not sufficient to initialize the PRNG from a external web server, DHCP server, or anything like that. That’s because network connections are likely to become available too late in the boot-up process. As you can see from the numbers tabulated in, a lot

of water has flowed under the bridge before the network devices come up, and IMHO it would be a Bad Idea to assume (or require) that nobody can do anything random until this-or-that network device has come up, let alone completed the DHCP process.

• The system might have a fixed address, or some other reason for not doing DHCP at all.
• The network interface might be a USB dongle that gets hotplugged long after the system has come up, if at all.
• etc. etc. etc.

It could be argued that it is “sometimes” OK for everybody to wait, but that argument doesn’t cut it. The shoe is on the other foot. Showing that a system is secure requires showing that it is always secure.

Here’s an example: The SSH system needs to cut host keys the first time it is used (if not sooner), and this requires high-quality randomly-drawn bits. As you can see in the tables in, the ssh server comes up early ... before the network devices, and before the urandom script loads the seed file.

Requiring sshd to start later is not a real solution, either. For one thing, this is just one example among many; there are many processes consuming many thousands of bytes, and you can’t make them all wait. Also note that it may necessary to do “ssh root@localhost” in order to configure the network ... in which case relying on network timing to seed the PRNG fails miserably.

This stands in contrast to the stored-seed approach, which has the advantage that the seed can be made available very, very early in the boot-up process ... if things are done properly.