This is an attempt to summarize a wide-ranging discussion
and see if we have a consensus.
There's been much discussion on at least three lists:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
of design of random number generators in general and
Linux /dev/random in particular. Much of it is archived
on a /dev/random page at:
http://www.openpgp.net/random/
Some of the ideas in the discussion are from papers
on the Counterpane site, analyzing other random number
generators with respect to various attacks and
proposing their own:
http://www.counterpane.com/pseudorandom_number.html
http://www.counterpane.com/yarrow.html
Two problems provoked this discussion, one a question
on coderpunks as to whether any analysis of /dev/random
had been done and the second some very specific concerns
raised on linux-ipsec that it might not work well on an
IPSEC gateway machine (or other server using crypto: SSL,
SSH, ...) where demand for random numbers is heavy and
neither keyboard nor mouse provides useful entropy.
Conclusions I've reached that I hope there's agreement on:
More analysis is needed, especially in the area of how
to estimate input entropy.
(Yarrow does this quite differently than /dev/random.
I'm not convinced either is right, but I've nothing
else to propose. This is clearly a hard problem.)
There could be a serious weakness on a gateway machine.
At a minimum, such machines should use the largest
possible entropy pool (2K 32-bit words for current
/dev/random) and enable all entropy sources.
Yarrow's two-stage design, where the output from
hashing the pool seeds a pseudo-random number
generator based on a strong block cipher, offers
significant advantages over the one-stage design
in /dev/random which delivers hash results as
output. In particular, it makes the hash harder
to attack since its outputs are never directly
seen, makes denial-of-service attacks based on
depleting the generator nearly impossible, and
"catastrophic reseeding" prevents iterative
guessing attacks on generator internal state.
So possible actions are:
Continue discussions on cryptography list,
focussing on the hardest problem: acquiring and
estimating entropy.
FreeS/WAN project should take steps in docs or
scripts to ensure /dev/random is appropriately
compiled on gateway systems.
/dev/random should become two-stage, preferably
using an AES candidate cipher with 256-bit key,
128-bit block and reseeding operations which
change at least 128 bits at a time.
I'll make a detailed proposal for that in
another post.
