21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Note that cryptographic pseudo-random number generators always produce an identical<br />

stream of output when identically seeded. If you wish to repeat a stream of<br />

numbers, you should avoid reseeding the generator (or you need to do the exact<br />

same reseeding at the exact right time).<br />

Discussion<br />

Most common “random number generators,” which we will call noncryptographic<br />

pseudo-random number generators, are not secure. They start with a seed (which<br />

needs to be random in and of itself to have any chance of security) and use that seed<br />

to produce a stream of numbers that look random from the point of view of a statistician<br />

who needs random-looking but reproducible streams of data.<br />

From the point of view of a good cryptographer, though, the numbers produced by<br />

such a generator are not secure. Generally, noncryptographic generators leak information<br />

about their internal state with each output, meaning that a good cryptographer<br />

can start predicting outputs with high accuracy after seeing a few random<br />

numbers. In a real system, you generally do not even need to see the outputs directly,<br />

instead inferring information about the outputs from the behavior of the program<br />

(which is generally made even easier with a bit of reverse engineering of the program).<br />

Traditional noncryptographic pseudo-random number generators include the rand( )<br />

and random( ) functions you’d expect to see in most libraries (so-called linear congruential<br />

generators). Other noncryptographic generators include the “Mersenne<br />

Twister” and linear feedback shift registers. If a random number generator is not<br />

advertised as a cryptographic random number generator, and it does not output<br />

high-entropy data (i.e., if it stretches out a seed instead of harvesting randomness<br />

from some external input to the machine), do not use it.<br />

Cryptographic pseudo-random number generators are still predictable if you somehow<br />

know their internal state. The difference is that, assuming the generator was<br />

seeded with sufficient entropy and assuming the cryptographic algorithms have the<br />

security properties they are expected to have, cryptographic generators do not<br />

quickly reveal significant amounts of their internal state. Such generators are capable<br />

of producing a lot of output before you need to start worrying about attacks.<br />

In the context of random number generation, entropy refers to the inherent<br />

“unknowability” of inputs to external observers. As we discuss in Recipe 11.19, it is<br />

essentially impossible to determine how unknowable something is. The best we can<br />

do is to establish conservative upper limits, which is, in and of itself, quite difficult.<br />

If a byte of data is truly random, then each of the 2 8 (256) possibilities are equally<br />

likely, and an attacker would be expected to make 2 7 guesses before correctly identifying<br />

the value. In this case, the byte is said to contain 8 bits of entropy (it can contain<br />

no more than that). If, on the other hand, the attacker somehow discovered that<br />

570 | Chapter 11: Random Numbers<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!