:In real life, machines don't always get rebooted in a completely :controlled fashion (panic, power failure, etc.). Anything that :makes a reboot longer or less reliable is a definite non-starter. : :I can guarantee you, if the current /dev/random code isn't fixed before :it makes STABLE, folks running servers 24/7 are going to rip it right :out. : : -Ed

I don't understand why /dev/random has to be reseeded with so many bytes in the first place... 64 or 128 bytes ought to do it, and if they don't then there is something fundamentally wrong with /dev/random that needs to be addressed. The proper way to address is NOT to try to push a larger seed into it. Hell, a *4* byte reseeding should generate sufficient randomness for our purposes (though obviously it is not cryptographically secure enough).

I am certainly not willing to wait more then 500ms on boot for /dev/random to seed, and I doubt very many other people would be either.

In regards to 'reboot' verses 'shutdown' ... the solution here is simple: don't try to save the random seed from the shutdown script. I would argue that the very *LAST* thing you want to do when shutting a machine down is start writing out files. And, frankly, depending on people using 'shutdown' is silly since most people run their machines either until they drop, or use 'reboot' rather then 'shutdown'.

The solution is to deal with entropy at boot time, and also regenerate the file from /etc/periodic/daily.

At boot time you do this:

* load the entropy file (128 bytes is plenty!) * fold in the current time (including microseconds) * fold in the "/" directory's mtime * fold in some junk from /var/log and dmesg. * save the entropy file * done.

From /etc/periodic/daily you do this:

* generate a random number * store it as the entropy file (128 bytes is plenty!)

-Matt

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message