Messages in this thread | | | Date | Sun, 25 May 2008 19:27:12 -0400 | From | Theodore Tso <> | Subject | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
| |
On Mon, May 26, 2008 at 12:39:49AM +0930, Glen Turner wrote: > > For example, /dev/random has run out. So the output of /dev/urandom > is now determined by previous values of /dev/random. I then send in > a stack of network packets at regular intervals. So the output of > /dev/urandom is now greatly determined by those packets. My search > space for the resulting key is small since /dev/urandom appears to > be random, but in fact is periodic.
That's not how it works. Basically, as long as there is *some* entropy in the system, even from the /var/lib/random-seed, or from keyboard interrupts, or from mouse interrupts, which is unknown to the attacker, in the worse case /dev/urandom will be no worse than a cryptographic random number generator.
Even if you feed it huge amounts of known data, it won't allow you to "influence" the cryptographic random number generator --- unless of course SHA-1 is totally and thoroughly broken as a cryptographic hash algorithm (invalidating all public key certificates and digital signatures made using SHA-1 algorithm).
There is a reason why /dev/random is world-writeable; it's perfectly safe to write arbitary amounts of data into /dev/random. If the attacker doesn't know what has been fixed into the entropy pool, his life just got a lot harder. If it is the attacker mixing known data into the pool, it's no worse.
The problems with /dev/urandom only appear if there *all* of the data is known by the attacker --- so all of the keyboard interrupts, all of the network interrupts, all of the mouse interrupts, the initial random seed file --- everything. In practice the time when this has come up is very early in the initial install process, where there is no random seed file, and before any interrupt entropy has had a chance to be mixed into the pool, particularly if it is a headless (i.e., no keyboard, no mouse, no monitor) install process.
And here there is no magic bullet. If you are doing a headless install, and there is no entropy, and you don't have a way of accessing a real hardware random number generator, THIS IS NOT THE RIGHT TIME TO BE GENERATING SSH HOST KEYS.
> I'll also note that there is a huge number of periodic packets seen by > hosts on quiet networks -- such as a preparation VLAN where a system > administrator might choose to run up a new machine.
If the attacker has the power to monitor your preparation/installation network exactly when the machine is being installed, you probably have worse problems on your hands --- for example, most distribution installs off of CD include the RPM, and then get on the network to grab the security updates. If you have an attacker on your preparation/install VLAN, they might be able to attack your machine and install rootkit before you have a chance to install the security errata RPM's. That would be much simpler than trying to record all of the network packet arrival times so you can try to guess the random number generator!
- Ted
| |