23.8 Picking a Random Seed

Using a good random number generator is easy. Picking a random seed, on the other hand, can be quite difficult. Conceptually, picking a random number should be easy: pick something that is always different. But in practice, picking a random number-especially one that will be used as the basis of a cryptographic key-is quite difficult. The practice is difficult because many things that change all the time actually change in predictable ways.

A stunning example of a poorly chosen seed for a random number generator appeared on the front page of the New York Times [14] in September 1995. The problem was in Netscape Navigator, a popular program for browsing the World Wide Web. Instead of using truly random information for seeding the random number generator, Netscape's programmers used a combination of the current time of day, the PID of the running Netscape program, and the Parent Process ID (PPID). Researchers at the University of California at Berkeley discovered that they could, through a process of trial and error, discover the numbers that any copy of Netscape was using and crack the encrypted messages with relative ease.

[14] John Markoff, "Security Flaw Is Discovered in Software Used in Shopping," The New York Times,September 19, 1995 p.1.

Another example of a badly chosen seed generation routine was used in Kerberos version 4. This routine was based on the time of day XORed with other information. The XOR effectively masked out the other information and resulted in a seed of only 20 bits of predictable value. This reduced the key space from more than 72 quadrillion possible keys to slightly more than one million, thus allowing keys to be guessed in a matter of seconds. When this weakness was discovered at Purdue's COAST Laboratory, conversations with personnel at MIT revealed that they had known for years that this problem existed, but the patch had somehow never been released.

In the book Network Security, Private Communication in a Public World, Kaufman et al identify three typical mistakes when picking random-number seeds:

1. Seeding a random number generator from a limited space.

   If you seed your random number generator with an 8-bit number, your generator only has one of 256 possible initial seeds. You will only have 256 possible sequences of random numbers coming from the function (even if your generator has 128 bytes of internal state).

2. Using a hash value of only the current time as a random seed.

   This practice was the problem with the Netscape security bug. The problem was that even though the UNIX operating system API appears to return the current time to the nearest microsecond, most operating systems have a resolution considerably coarser-usually within one 1/60th of a second or less. As Kaufman et al point out, if a clock has only 1/60th of a second granularity, and the intruder knows to the nearest hour at what time the current time was sampled, then there are only 60x60x60 = 216,000 possible values for the supposedly random seed.

3. Divulging the seed value itself.

   In one case reported by Kaufman et al, and originally discovered by Jeff Schiller of MIT, a program used the time of day to choose a per-message encryption key. The problem in this case was that the application included the time that the message was generated in its unencrypted header of the message.

How do you pick a good random number? Here are some ideas:

1. Use a genuine source of randomness, such as a radioactive source, static on the FM dial, thermal noise, or something similar.

   Measuring the timing of hard disk drives can be another source of randomness, provided that you can access the hardware at a sufficiently low level.

2. Ask the user to type a set of text, and sample the time between keystrokes.

   If you get the same amount of time between two keystrokes, throw out the second value; the user is prob- ably holding down a key and the key is repeating. (This technique is used by PGP as a source of randomness for its random number generator.)

3. Monitor the user.

   Each time the user presses the keyboard, take the time between the current keypress and the last keypress, add it to the current random number seed, and hash the result with a cryptographic hash function. You can also use mouse movements to add still more randomness.

4. Monitor the computer.

   Use readily available, constantly changing information, such as the number of virtual memory pages that have been paged in, the status of the network, and so forth.

In December 1994, Donald Eastlake, Steve Crocker, and Jeffrey Schiller prepared RFC 1750, which made many observations about picking seeds for random number generators. Among them:

1. Avoid relying on the system clock.

   Many system clocks are surprisingly non-random. Many clocks which claim to provide accuracy actually don't, or they don't provide good accuracy all the time.

2. Don't use Ethernet addresses or hardware serial numbers.

   Such numbers are usually "heavily structured" and have "heavily structured subfields." As a result, one could easily try all of the possible combinations, or guess the value based on the date of manufacture.

3. Beware of using information such as the time of the arrival of network packets.

   Such external sources of randomness could be manipulated by an adversary.

4. Don't use random selection from a large database (such as a CD-ROM) as a source of randomness.

   The reason, according to RFC 1750, is that your adversary may have access to the same database. The database may also contain unnoticed structure.

5. Consider using analog input devices already present on your system.

   For example, RFC 1750 suggests using the /dev/audio device present on some UNIX workstations as a source of random numbers. The stream is further compressed to remove systematic skew. For example:

$ cat /dev/audio | compress - >random-bit-stream

RFC 1750 advises that the microphone not be connected to the audio input jack, so that the /dev/audio device will pick up random electrical noise. This rule may not be true on all hardware platforms. You should check your hardware with the microphone turned on and with no microphone connected to see which way gives a "better" source of random numbers.