: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
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
From /etc/periodic/daily you do this:
* generate a random number
* store it as the entropy file (128 bytes is plenty!)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message