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
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.
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
In the book Network Security,
Private Communication in a Public
identify three typical mistakes when picking
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
Using a hash value of only the current
time as a random
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
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.
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
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
Ask the user to type a set of text, and sample the time between
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.)
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.
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
In December 1994, Donald Eastlake, Steve Crocker, and Jeffrey
1750, which made many observations about picking seeds for random number generators.
Avoid relying on the
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.
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
Beware of using information such as the time of the arrival of
Such external sources of randomness could be manipulated by an
Don't use random selection from a large database (such as a CD-ROM) as a source of
The reason, according to RFC 1750, is that your adversary may have access to
the same database. The database may also contain unnoticed structure.
Consider using analog input devices already present on your
For example, RFC 1750
suggests using the
device present on some UNIX workstations as a source of
random numbers. The stream is further compressed to remove systematic skew. For
cat /dev/audio | compress - >random-bit-stream
RFC 1750 advises that the microphone not be connected to the
audio input jack, so that the
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.