[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RNG Resource FAQ (was Re: "random" number seeds vs. Netscape)
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 <[email protected]>
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