Re: [Pkg-sysvinit-devel] Bug#587665: Safety of early boot init of /dev/random seed

[Matt Mackall <mpm@selenic.com>]

On Sat, 2010-07-03 at 13:08 -0300, Henrique de Moraes Holschuh wrote:
> (adding Petter Reinholdtsen to CC, stupid MUA...)
> 
> On Sat, 03 Jul 2010, Henrique de Moraes Holschuh wrote:
> > Hello,
> > 
> > We are trying to enhance the Debian support for /dev/random seeding at early
> > boot, and we need some expert help to do it right.  Maybe some of you could
> > give us some enlightenment on a few issues?
> > 
> > Apologies in advance if I got the list of Linux kernel maintainers wrong.  I
> > have also copied LKML just in case.
> > 
> > A bit of context:  Debian tries to initialize /dev/random, by restoring the
> > pool size and giving it some seed material (through a write to /dev/random)
> > from saved state stored in /var.
> > 
> > Since we store the seed data in /var, that means we only feed it to
> > /dev/random relatively late in the boot sequence, after remote filesystems
> > are available.  Thus, anything that needs random numbers earlier than that
> > point will run with whatever the kernel managed to harness without any sort
> > of userspace help (which is probably not much, especially on platforms that
> > clear RAM contents at reboot, or after a cold boot).
> > 
> > We take care of regenerating the stored seed data as soon as we use it, in
> > order to avoid as much as possible the possibility of reuse of seed data.
> > This means that we write the old seed data to /dev/random, and immediately
> > copy poolsize bytes from /dev/urandom to the seed data file.
> > 
> > The seed data file is also regenerated prior to shutdown.
> > 
> > We would like to clarify some points, so as to know how safe they are on
> > face of certain error modes, and also whether some of what we do is
> > necessary at all.  Unfortunately, real answers require more intimate
> > knowledge of the theory behind Linux' random pools than we have in the
> > Debian initscripts team.
> > 
> > Here are our questions:
> > 
> > 1. How much data of unknown quality can we feed the random pool at boot,
> >    before it causes damage (i.e. what is the threshold where we violate the
> >    "you are not goint to be any worse than you were before" rule) ?

There is no limit. The mixing operations are computationally reversible,
which guarantees that no unknown degrees of freedom are clobbered when
mixing known data.

> > 2. How dangerous it is to feed the pool with stale seed data in the next
> >    boot (i.e. in a failure mode where we do not regenerate the seed file) ?

Not at all.
 
> > 3. What is the optimal size of the seed data based on the pool size ?

1:1.

> > 4. How dangerous it is to have functions that need randomness (like
> >    encripted network and partitions, possibly encripted swap with an
> >    ephemeral key), BEFORE initializing the random seed ?

Depends on the platform. For instance, if you've got an unattended boot
off a Live CD on a machine with a predictable clock, you may get
duplicate outputs.

> > 5. Is there an optimal size for the pool?  Does the quality of the randomness
> >    one extracts from the pool increase or decrease with pool size?

Don't bother fiddling with the pool size.

> > Basically, we need these answers to find our way regarding the following
> > decisions:
> > 
> > a) Is it better to seed the pool as early as possible and risk a larger time
> >    window for problem (2) above, instead of the current behaviour where we
> >    have a large time window where (4) above happens?

Earlier is better.

> > b) Is it worth the effort to base the seed file on the size of the pool,
> >    instead of just using a constant size?  If a constant size is better,
> >    which size would that be? 512 bytes? 4096 bytes? 16384 bytes?

512 bytes is plenty.
 
> > c) What is the maximum seed file size we can allow (maybe based on size of
> >    the pool) to try to avoid problem (1) above ?

Anything larger than a sector is simply wasting CPU time, but is
otherwise harmless.

-- 
Mathematics is the supreme nostalgia of our time.