Messages in this thread | | | Date | Tue, 29 May 2007 17:31:12 +0200 | From | "Jesper Juhl" <> | Subject | Re: Seeding /dev/random not working |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |