Problem - Kevin Tafuro

don’t think you should worry about this issue in practice. (There are almost always
bigger fish to fry.)
Second, depending on the operating system, the entropy produced by /dev/random
may be reused by /dev/urandom. While few (if any) Unix platforms try to guarantee a
clean separation of entropy, this is more of a theoretical problem than a practical
problem; it is not something about which we personally would worry. Conversely,
depending on the operating system, use of /dev/urandom can drain entropy, denying
service to the /dev/random device.
Finally, most operating systems do not actually guarantee that /dev/urandom is properly
seeded. To understand why, you need to know something about what generally
goes on under the hood. Basically, the randomness infrastructure tries to cull randomness
from user input. For example, tiny bits of entropy can be derived from the
time between console keystrokes. Unfortunately, the system may start up with very
little entropy, particularly if the system boots without user intervention.
To avoid this problem, most cryptographic pseudo-random number generators
stash away output before the system shuts down, which is used as a seed for the
pseudo-random number generator when it starts back up. If the system can reboot
without the seed being compromised (a reasonable assumption unless physical
attacks are in your threat model, in which case you have to mitigate risk at the physical
level), /dev/urandom will produce good results.
The only time to get really paranoid about a lack of entropy is before you are sure the
infrastructure has been seeded well. In particular, a freshly installed system may not
have any entropy at all. Many people choose to ignore such a threat, and it is reasonable
to do so because it is a problem that the operating system should be responsible
for fixing.
However, if you want to deal with this problem yourself, be aware that all of the
operating systems that have a /dev/random device (as far as we can determine) monitor
all keyboard events, adding those events to their internal collection of entropy.
Therefore, you can use code such as that presented in Recipe 11.20 to gather sufficient
entropy from the keyboard, then immediately throw it away (because the operating
system will also be collecting it). Alternatively, you can collect entropy yourself
using the techniques discussed in Recipes 11.22 and 11.23, then run your own cryptographic
pseudo-random number generator (see Recipe 11.5).
The /dev/random and /dev/urandom devices behave just like files. You should read
from these devices by opening the files and reading data from them. There are a few
common “gotchas” when using that approach, however. First, the call to read data
may fail. If you do not check for failure, you may think you got a random number
when, in reality, you did not.
Second, people will occasionally use the API functions improperly. In particular, we
have seen people who assume that the read( ) or fread( ) functions return a value or
576 | Chapter 11: Random Numbers
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.