> I stated this same objection until I actually attended Mark's
> presentation at the 'con. The yarrow algorithm uses an encrypted hash for
> the entropy on the way in, and encrypts the output on the way out. This
> would make it extremely difficult to guess the state at reboot, even if we
> weren't picking up new entropy sources during the boot process.
There is an angle; an attacker can attack by replaying, but this requires
strong privelige.
> Pending Mark's approval, I'd like to suggest we add a cron job to
> dump X k of data from /dev/random to a file (/boot/.periodic_entropy
> maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
> boot, and only do the "long, annoying" failover process if neither file
> exists. The only remaining questions would be how many k of data to dump
> how often.
I like that, but I'd like to see more than one file. This avoids the race
where fsck may blat an incompletely written file after a (in)convenient
crash.
We are really headed towards saving state in the first swap partition
(if there is one).
On a related note, I'd like to see mergemaster rebuild /dev if it is not
DEVFS (obviously taking into account user preferences in MAKEDEV.local).
I believe that users are shootin their feet by not tracking /dev properly.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
