Famous random breakdowns

Nothing beats real-world examples. These three incidents affected widely deployed systems, and none of them stemmed from a flaw in the algorithm.

Netscape, 1995

The very first SSL derived its seed from the current time, the process ID and the parent process ID.

Two students, Goldberg and Wagner, realised that these three values were easily guessable by anyone observing the machine. The actual key space was reduced to a few dozen bits, and session keys were compromised within a minute.

The algorithm was correct. The seed was not.

Debian, 2008

A maintainer cleaned up the OpenSSL code following a warning from an analysis tool. He removed a line which, unintentionally, was feeding the generator with uninitialised data.

There was now only one remaining source: the process number. That is, 32,768 possible values.

2^1024    (expected items)
32768     (scenarios that are actually possible)

For nearly two years, all SSH and SSL keys generated on Debian and its derivatives were drawn from this tiny set. All that was needed was to pre-compute them all. The mass key replacement that followed remains one of the largest ever organised.

The PlayStation 3, 2010

ECDSA requires a random number k that is different for each signature. Sony used a constant.

The consequence is mathematical and immediate: two signatures produced with the same k make it possible to solve a small system of equations and extract the private key. The key used to sign the console’s games was published, and could not be changed without rendering existing consoles unusable.

What we can learn from this

These three cases have one thing in common: the algorithm itself was not at fault. SSL, RSA and ECDSA did exactly what was expected of them.

It was the randomness that was lacking, and the failure remained undetectable — a faulty generator produces outputs that appear perfectly normal. You cannot spot a faulty generator simply by looking at its numbers.

Hence the rule: never build your own generator; ask the system for one, and pay particular attention to the initialisation phase.