Messages in this thread | | | Date | Tue, 29 May 2007 09:15:01 -0400 | From | Theodore Tso <> | Subject | Re: Seeding /dev/random not working |
| |
On Tue, May 29, 2007 at 12:53:10PM +0100, M Macnair wrote: > 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.
Secondly, and more importantly, your boot scripts aren't set up correctly. You really want to make sure that you save the some entropy at shutdown. i.e., run at shutdown the same sequence that was run at the boot-time. (You don't really need the "cat $random_seed > /dev/urandom", but it's harmless.) Repeating this sequence at shutdown is useful because it saves any entropy gathered from the current boot session and saves it to be used at the next boot session. I've noticed a number of distro's have gotten this wrong, and I guess I should have filed more bugs to get this fixed. In your case, since you don't have anything wired up to feed entropy into your pool, it will make /dev/urandom effectively a psuedo-random number generator, but at least you won't get repeating outputs.
Another thing which I noticed is that when Matt Mackall took over maintainership of /dev/random, he apparently took out one of the safeguards I had, which was that before, when entropy was extracted from the pool the time stamp when it was extracted was mixed back into the pool. The theory was that an external attacker might not know when a program might be calling /dev/random, so mixing in the time of that entropy was extracted wouldn't hurt, and might help. I'll submit a patch to add that support back in, which will help you a little.
HOWEVER, the more important thing to remember is that /dev/random isn't magic. If you don't have any entropy sources to mix in, and you don't do anything at the application level to mix in data that might not be known by external attackers, you will always be vulnerable, especially if your threat model includes government funded intelligence agencies. So if you are planning on using /dev/urandom for cryptographic purposes, while some of these fixes will avoid at least the embarassing result of repeating outputs from /dev/urandom, it's not really going to result in high-quality unpredictable results against a well-funded, determined adversary.
If that is your threat model, then you really should consider adding hardware random number generator into your product design.
Regards,
- Ted - 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/
| |