entropy depletion (was: SSL/TLS passive sniffing)

[William Allen Simpson]

Wondering how in the world we got into this endless debate, I went back
and re-read the entire thread(s).  I think that early comments were
predictive, where Ian Grigg wrote:

>                                           ... Crypto is
>
>such a small part of security that most all crypto people
>move across to general security once they realise there
>isn't much work around for a pure crypto person.  Which is
>good, because only in the general security field can one
>really make a difference, IMHO, because that's when starts
>to understand what is needed, as opposed to what's cool.
>
>
It was Denker that jumped off into the realm of entropy density (again)
(Message-ID: <41C9A58E.7090203 at av8n.com>), recommending that nobody use
/dev/urandom.  He's right about entropy in the strict theoretical sense,
but wrong about our _need_ for practical security.

As David Wagner wrote with regard to another such claim:

> (That poster wants you to believe that, since /dev/urandom uses a
>
>cryptographic-strength pseudorandom number generator rather than a
>true entropy source, it is useless.  Don't believe it.  The poster is
>confused and his claims are wrong.)
>
>
And John Kelsey recently wrote:

>... The critical question is whether the PRNG part gets to a secure state, which basically means a state the attacker can't guess in the amount of work he's able to do.   If the PRNG gets to a secure state before generating any output, then assuming the PRNG algorithm is secure, the outputs are indistinguishable from random.  
>
>
There are already other worthy comments in the thread(s).  We are using
computational devices, and therefore computational infeasibility is the
standard that we must meet.  We _NEED_ "unpredictability" rather than
"pure entropy".

So, here are my handy practical guidelines:

 (1) As Metzger so wisely points out, the implementations of /dev/random,
/dev/urandom, etc. require careful auditing.  Folks have a tendency to
"improve" things over time, without a firm understanding of the
underlying requirements.

 (2) The non-blocking nature of /dev/urandom is misunderstood.  In fact,
/dev/urandom should block while it doesn't have enough entropy to reach
its secure state.  Once it reaches that state, there is no future need
to block.

 (2A) Of course, periodically refreshing the secure state is a good
thing, to overcome any possible deficiencies or cycles in the PRNG. 

 (2B) I like Yarrow.  I was lucky enough to be there when it was first
presented.  I'm biased, as I'd come to many of the same conclusions,
and the strong rationale confirmed my own earlier ad hoc designs.

 (2C) Unfortunately, Ted Ts'o basically announced to this list and
others that he didn't like Yarrow (Sun, 15 Aug 1999 23:46:19 -0400).  Of
course, since Ted was also a proponent of 40-bit DES keying, that depth
of analysis leads me to distrust anything else he does.  I don't know
whether the Linux implementation of /dev/{u}random was ever fixed.

 (3) User programs (and virtually all system programs) should use
/dev/urandom, or its various equivalents.

 (4) Communications programs should NEVER access /dev/random.  Leaking
known bits from /dev/random might compromise other internal state.

Indeed, /dev/random should probably have been named /dev/entropy in the
first place, and never used other than by entropy analysis programs in
a research context.

 (4A) Programs must be audited to ensure that they do not use
/dev/random improperly.

 (4B) Accesses to /dev/random should be logged.

-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com