Summary

  • RFC 1750 warned that a long, statistically convincing secret could come from a much smaller set of plausible seeds. An attacker who knew roughly when a machine started could search that set instead of the key's advertised space.
  • Clocks, serial numbers, keystrokes and packet timing offered different kinds of input, but each brought assumptions about resolution, structure, sampling or adversarial influence. RFC 4086 later expanded the account of entropy sources and pools.

Imagine a key generator handing you a beautiful river of digits. They look irregular. They pass a glance test. The machine can produce more whenever you ask. Then its opponent asks a much shorter question: what time did the machine start?

That was the trap laid out in RFC 1750, published in December 1994. Software cryptography was moving into network life, and secret numbers sat beneath passwords, keys and other protections. The authors looked upstream of the cryptographic algorithm. If the generator started from a clock reading, and the attacker knew the approximate startup window, the attacker's list of likely seeds might be short. Each candidate could be run through the same generator. The long river of output had flowed from a narrow spring.

This was an argument about uncertainty to the attacker. A conventional pseudo-random sequence can look excellent in a statistical test and still be deterministic once its starting state is known. RFC 1750 used a public CRC table as an especially rude example: its numbers could have attractive statistical properties, yet anyone who knew the table could reproduce them. Appearance and secrecy had wandered into the same room wearing each other's badges.

Clocks made the confusion easy to miss. A clock interface might report microseconds. That many digits looked like a rich source of surprise. The RFC warned that the actual low bits varied across machines: some repeated; some advanced through operating-system bookkeeping rather than fresh physical variation. Even two supposedly similar systems could expose quite different timing behavior. A serial number had the opposite costume, a unique-looking identity whose manufacturer and product structure might sharply reduce what an outsider needed to guess.

A field's width was an engineering specification; its unpredictable portion was an adversarial question.

The authors explored more promising messengers: mouse motion, the intervals between keystrokes and the timing of incoming packets. None arrived with a universal entropy label attached. Keyboard buffering could hide the useful timing from an application. People could type repetitively. A remote adversary might influence packet arrival times. The problem was to collect variation that an opponent could neither know nor steer, and to know what the collection process had actually retained. Merely reading an event counter was no audit of its origins.

Then came the memo's central joke at the computer's expense. Feed a complex generator the current time as its seed. Let it perform ingenious transformations and print a great many random-looking bits. The attacker who can bracket startup still tests the plausible times. More output supplies more material to compare; it does not enlarge the initial guest list. RFC 1750 warned that blind complexity could even spoil a genuinely good seed. The generator was an accomplished chef who had been handed three ingredients and kept presenting a thousand dishes.

Another example made the same point without a clock. The memo imagined selecting bytes from a large USENET store available to the adversary too. The store's size was not the secret. Under the stated assumptions, only the choice of starting position contributed uncertainty; in that historical example the RFC put its upper bound around 25 bits. The number belongs to that example's 1994 setup. Its lasting lesson is simpler: public material does not become private because somebody took a small, concealed scoop from it.

The RFC consequently treated source collection, mixing and output generation as separate jobs. A physical phenomenon could supply unpredictability. A mixing function could combine and spread it. A generator could turn an adequately secret state into useful output. Each stage carried a different burden. Strong mathematics at the last stage could preserve a good input; it could not conjure the missing input after the fact. For an operator deciding whether to trust a key, the interesting receipt began before the first hexadecimal digit appeared.

RFC 4086 in June 2005 replaced the 1994 memo and broadened the discussion to ring oscillators, entropy pools and then-current operating-system generators. That revision shows how quickly the practical sources and machinery changed. The question RFC 1750 made impossible to ignore survived the update: who had measured the unpredictability at the start of the chain? A key can be long enough to impress everyone in the room. The attacker may still be checking the clock.