2.10 Randomness

The keys used in digital security must be generated "randomly." For our purposes, "random" is defined as hard to guess, so this makes it more difficult to guess the key. This goal turns out to be surprisingly challenging to achieve on a computer. One strategy is to use true physical randomness such as thermal noise or radioactive decay, but it requires special hardware and usually produces random bits fairly slowly. More commonly, systems use algorithmic "pseudo-random" number generators. Unfortunately, to be unguessable, they initially require some sort of strong random seed value. Frequently such a seed can be derived from some hardware source of randomness.

Many real-world systems that did almost everything else right have been broken due to weak random numbers. Perhaps they based their random number generation on a seed that uses only the time and date. As a result, anyone with a general idea of when the seed was generated will have an embarrassingly small space to search through to find the key possibly only a few dozen values even if the key is 128 bits and should have 2¹²⁸ equally probable values.

For a deeper and more detailed discussion of these issues, see [RFC 1750] and [Schneier].

Early versions of Netscape Navigator, although they did most everything else correctly in terms of security, depended (as have other security critical software products) on a library "random" number generator for SSL keys. On some platforms, this generator used the time of day and process ID as a seed. Its output was relatively easy to guess. This problem has, of course, been fixed. Because it drew a bit of attention, people have become more cautious about this issue. But give it a few years and likely someone will make the same mistake again. It's very easy to put in a "temporary" weak random number generator while developing a system and never get around to upgrading it.