Perry Metzger writes: # You might want to read RFC 1750, Phil Karlton writes:

Did that. It talks about a lot of the pitfalls. Unfortunately it does not address (nor can it realistically be expected to address) details of what to look for on a particular version of an OS running on some particular platform.

Can someone point me to a compilation of such information ? If not, I'm definitely interested in starting a Web page to chronicle recommendations about good, bad, and questionable random and pseudo-random sources for specific architectures and operating systems. (It could also include information on special-purpose plug-in hardware RNGs.) -Futplex <futplex@pseudonym.com> Having overcome my initial skepticism on the entire topic of entropy, based on the useful pointers to the literature I have received, I agree wholeheartedly with the need for _positive_ design criteria against which designs may be evaluated. For initial consideration, I recommend the following: The entropy E is defined by the sum across n states of -P_i log_2(P_i), where i ranges from 1 to n, and P_i is the probability of state i. In order for this expression to have meaning, the all four criteria of the following must be met: 1) The states exist and can be identified. 2) The number of states n is known. 3) The index value i uniquely identifies a state. 4) The function P_i is known and well-behaved. The designer should disprove the negative of each of these to arrive at a _concise_ statement of their "proof" of measured entropy equating to predicted entropy. For example, the designer should "disprove" the statements: "The states do not exist. Even if the states exist, they cannot be identified." by clearly stating the factors that lead to the existence of the states, and precisely why they can be identified. This provides a list of requirements (in effect) for a deployment to meet the expected entropy. I think that application of these criteria can rigorously explain the difficulties in using mouse movements, for example, as a source of entropy. In addition, the problems with clocks in PC emulations on Macs also speak to these criteria. Certainly the entropy available from pid is also explained here in a rigorous way. I would appreciate feedback on this as a foundation for a set of _positive_ design criteria for sources of entropy. If I have missed information in the literature that provides design guidance (not anecdotal pitfalls, which are very valuable but lack rigor in the cases I have seen), I would very much appreciate that as well. A special thanks to Tim May for his references. dvw