Problem - Kevin Tafuro

with a high-resolution clock (i.e., one running in the GHz range). If your clock has
better than millisecond resolution and the processor is modern, it is probably reasonable
to assume a half-bit of entropy on incoming network packets, even if the packets
are generated by an attacker.
Entropy in the sound device
There is generally some entropy to be had by reading a sound card just from random
thermal noise. However, the amount varies depending on the hardware. Sound cards
are usually also subject to RF interference. Although that is generally not random, it
does tend to amplify thermal noise.
Conservatively, if a machine has a sound card, and its outputs do not fail FIPS-140
tests, we believe it is reasonable to estimate 0.25 bits per sample, as long as an
attacker cannot measure the same samples. Otherwise, do not estimate any.
Entropy from thread timing and other system state
Systems effectively gain entropy based on inputs from the environment. So far, we
have discussed how to estimate entropy by directly sampling the input sources. If
you wish to measure entropy that you are not specifically sampling, it is generally
feasible to query system state that is sensitive to external inputs.
In practice, if you are worried about local attacks, you should not try to measure system
state indirectly, particularly as an unprivileged user. For anything you can do to
measure system state, an attacker can probably get correlated data and use it to
attack your results.
Otherwise, the amount of entropy you get definitely depends on the amount of information
an attacker can guess about your source. It is popular to use the output of
commands such as ps, but such sources are actually a lot more predictable than most
people think.
Instead, we recommend trying to perform actions that are likely to be indirectly
affected by everything going on in the system. For example, you might measure how
many times it takes to yield the scheduler a fixed number of times. More portably,
you can do the same thing by timing how long it takes to start and stop a significant
number of threads.
Again, this works only if local users are not in your threat model. If they are not, you
can estimate entropy by looking at the difference between timestamps, as discussed
earlier in this recipe. If you want to be conservative in your estimates, which is a
good idea, particularly if you might be gathering the same entropy from different
sources, you may want to divide the basic estimate by two or more.
See Also
Recipes 11.5, 11.18
Performing Entropy Estimation and Management | 629
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.