Entropy collection in sshd (was Re: Entropy and DSA key)

[Ed Phillips]

What I don't understand about the internal entropy collection is why can't
sshd just run the commands periodically just like prngd, and keep a
running, stirred pool of random numbers to use when a client connects?
Why does sshd have to run every command and start, basically, from scratch
every time a client connects?  It seems like it'd be trivial for sshd just
have this feature built-in, with all the caveats documented like "This is
NOT actually PRNGD, but it may be good enough for your system that doesn't
have /dev/[u]random or if you can't run PRNGD or whatever."  Like Dave
said, sshd from ssh-1.2.27 just fired off the commands at startup, then
add to that a little at a time, on the fly.  On a system where there's not
a lot of activity (for example, an NFS server), 90% of the commands are
returning the same bytes over and over again, so it really doesn't matter
whether you run them once at startup, then periodically while sshd is not
doing anything (sshd is not actually doing anything on our departmental
systems 99.99% of the time - it could be running prng-like commands
occasionally while waiting for a connection), or whether you run them
every single time a client connects.  The drawbacks listed in WARNING.RNG
are, IMHO, a direct result of the implementation choices made for the
internal entropy collection.  I don't know a lot about the code for sshd,
but it's seems a simple thing to change (in theory) - having a constantly
updated pool of random bytes kept in the parent sshd process (which gets
updated by running prng-like commands periodically), and passing that pool
off to each spawned sshd child with a little system-call stirring after
forking (getpid(), gettimeofday(), etc. in the child before it needs to
grab some random bytes).

How many random bytes are required to process a client connection on the
server side?  We could make the pool big enough to allow for whatever the
maximum requirement is, right?

IMHO, it would be a "good thing" to make OpenSSH require fewer third-party
packages (don't get me wrong, PRNGD, /dev/random, etc. are nice).
OpenSSL is already a pretty severe requirement in terms of compile time -
and you can't get rid of that.  And sure, supporting a list of prng
commands for every platform is not something anyone really wants to do,
but why can't we just borrow the latest set from PRNGD for the next
OpenSSH release...  and let the user know that it really needs to be
customized for THEIR systems, just like with PRNGD itself.

Ah... I'm rambling...

Thanks for reading.

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key