On Thu, Jul 29, 2010 at 03:47:01PM -0400, Richard Salz wrote:
> At shutdown, a process copies /dev/random to /var/random-seed which is 
> used on reboots.
> Is this a good, bad, or "shrug, whatever" idea?

If the entropy pool has other, reasonable/fast sources of entropy at
boot time, then seeding the entropy pool at boot time with a seed
generated at shutdown time is harmless (assuming a good enough entropy
pool design).  Else, then this approach can be a good idea (see below).

> I suppose the idea is that "all startup procs look the same" ?

The idea is to get enough entropy into the entropy pool as fast as
possible at boot time, faster than the system's entropy sources might
otherwise allow.

The security of a system that works this way depends critically on
several things: a) no one reads the seed between the time it's generated
and the time it's used to seed the entropy pool, b) the seed cannot be
used twice accidentally, c) the system can cope with crashes (i.e., no
seed at boot) such as by blocking reads of /dev/random and even
/dev/urandom until enough entropy is acquired, d) the entropy pool
treats the seed as entropy from any other source and applies the normal
mixing procedure to it, e) there is a way to turn off this chaining of
entropy across boots.  (Have I missed anything?)

(a) can't really be ensured.  But one could be sufficiently confident
that (a) is true that one would want to enable this.  (d) means that
every additional bit of entropy obtained from other sources at boot time
will make it harder for an attacker that managed to read this seed to
successfully mount any attacks on you.  (e) would be for the paranoid;
for most users, most of the time, chaining entropy across reboots is
probably a very good idea.  But most importantly, on-CPU RNGs should
make this totally pointless (see previous RNG-on-CPU threads).

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to