Yesterday I discovered Yarrow, a free tool from Counterpane Internet Security (Bruce Schneier, et. al.) for generating cryptographically secure random bits. The problem I have with Yarrow, is that it depends on mouse movements and key presses. Yes, those may be good sources of randomness, but I think there must be a less intrusive way to collect randomness. How about collecting random bits without requiring anything from the user? Completely behind the scenes?
There is Intel's hardware random number generator, which works only on motherboards that use the Intel chipsets. That's a very good solution if you have a motherboard based on the Intel chipset and you don't mind installing the driver software.
On Linux and BSD variants, there is /dev/random or something similar. This is a very good solution.
But, what about Solaris? I am thinking about developing my own solution. It will gather kernel statistics using the kstat routines, and it will gather process statistics using by reading from files in /proc. All this information will be mixed together using the SHA-1 hash algorithm. Finally, and this is the real deal: it will use gethrtime to collect lots of timings at a very high precision. On my sparc machine, the precision is 180 ns. It seems that there is a lot of unpredictability in how much time is spent executing system calls. A program could therefore gather a lot of unpredictability by timing the system calls. Not only that, but you could estimate the amount of entropy by repeating the exact same system call multiple times and collecting statistics on the timings. It makes perfect sense to me, because if an attacker wanted to attack your random number source, he would run the same sequence of system calls, generate the timings, and use those timings to reduce the search space. If you collect stats on the timings, you can estimate the extent to which the attacker could limit the search space. For example, if a particular system call takes either 3 or 4 us with equal probability, that is one bit of randomness. An attacker could limit his search space to 3 or 4 for that particular source. But if you have 256 such sources, then the attacker has a very large search space! (In fact, my measurements indicate much more randomness than this simple example implies.) If I implement this, what it will provide is a source of random bits and a (conservative) estimate of the amount of entropy, with minimal intrusiveness (no mouse movements required). The only downside is that it will be very system-specific.
Posted by Doug Sauder at April 19, 2002 10:26 AM