Re: Seeding /dev/random not working

["Jesper Juhl" <jesper.juhl@gmail.com>]

On 29/05/07, M Macnair <mmacnair@gmail.com> wrote:
> On 5/29/07, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > > > I have two embedded boards (one ARM, one PowerPC), running two
> > > > different versions of 2.6.  They have no hard drives, keyboards or
> > > > mice.  They each have a NIC, but I understand these make no
> > > > contribution to the entropy pool.
> > > >
> > > >     if [ -f $random_seed ]; then
> > > >             cat $random_seed >/dev/urandom  # should seed the pool
> > > >     fi
> > > >     dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> > > > data from urandom for next boot
> > > >
> > > > I have rebooted my boards many times, and after each boot I read the
> > > > contents of $random_seed.  Whilst it does not happen every time, the
> > > > contents of $random_seed are /often the same/.  To give you a feel:
> > > > rebooted 11 times, got a total of 3 different outputs.
> > >
> > > Ok, so this is telling me a couple of things.  First of all, if you're
> > > only getting three outputs, it means that you don't have any
> > > peripherals feeding entropy into the system from the boot sequence.
> > > Without any hard drives, keyboards or mice, and a NIC whose device
> > > driver hasn't been configured to feed entropy, you're definitely
> > > hosed.
> >
> > Can we get at least time-of-boot from rtc clock to the pool? We really
> > should not be getting identical outputs...
>
> Ah yes that is one thing I forgot to mention - when you turn these
> boards off, you really do turn them off - no battery means no clock.
> They wake up every time in 1970.
>
> I am planning on providing my own entropy to this system by feeding
> /dev/random (which leads to the problem of it not working...).

Depending on how high quality randomness you need, you could just let
your NIC driver provide entropy by changing interrupt handlers to use
SA_SAMPLE_RANDOM.
Sure, getting entropy that way allows an outside attacker to influence
the pool if they can obtain a high degree of control over what data
you recieve and when, but in most realistic scenarios it should be
acceptable (and it's certainly better than no entropy at all).

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html