Practical UNIX & Internet Security

Practical UNIX & Internet SecuritySearch this book
Previous: 23.7 UNIX Pseudo-Random FunctionsChapter 23
Writing Secure SUID and Network Programs
Next: 23.9 A Good Random Seed Generator

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).


    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.


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




    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.


  4. Monitor the computer.


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.


    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.



    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:


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.

Previous: 23.7 UNIX Pseudo-Random FunctionsPractical UNIX & Internet SecurityNext: 23.9 A Good Random Seed Generator
23.7 UNIX Pseudo-Random FunctionsBook Index23.9 A Good Random Seed Generator