From: David Van Wie <dvw@hamachi.epr.com>
Date: Fri, 22 Sep 95 17:50:33 PDT
To: "'cypherpunks'" <cypherpunks@toad.com>
Subject: RE: RNG Resource FAQ (was Re: "random" number seeds vs. Netscape)
Message-ID: <30635951@hamachi>
MIME-Version: 1.0
Content-Type: text/plain



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