Entropy and DSA key

[Ed Phillips]

On Tue, 6 Nov 2001, Dan Astoorian wrote:

> Date: Tue, 6 Nov 2001 13:23:58 -0500
> From: Dan Astoorian <djast at cs.toronto.edu>
> To: Dave Dykstra <dwd at bell-labs.com>
> Cc: Ed Phillips <ed at UDel.Edu>
> Subject: Re: Entropy and DSA key
>
> On Tue, 06 Nov 2001 10:54:12 EST, Dave Dykstra writes:
> > > On Mon, 5 Nov 2001, Ed Phillips wrote:
> > >
> > > > Is there any way to compile openssh so that it will use prngd, but if it'
> > s
> > > > not answering, use the compiled-in prng-like routines?
> >
> > In addition to Dan Astoorian's suggestion, you could try my patch which is
> > in the mailing list archive in a thread beginning at
> >
> >     http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99193668118573&w=2
> >
> > It allows you to select any of /dev/random, prngd, or internal entropy
> > sources and if it can't find one it will go on to the next.
>
> (Removed openssh-unix-dev and others from recipients--it's getting noisy
> in here.)
>
> Correct me if I'm wrong, Dave, but my recollection is that your patch
> goes on to the next method if it finds that prngd is not _configured_
> (i.e., if the socket doesn't exist), as distinct from if it's "not
> answering."  If PRNGD has died, your patch doesn't use internal entropy
> sources.  Mine does fall back in that case, but is a bit less efficient
> in the general case (because it always writes a seed file even when
> connecting to PRNGD, for example).
>
> It's not clear to me which problem Ed was looking to solve, but I
> thought this was worth pointing out.

I was hoping that OpenSSH could be compile (with some configure options
that already exist)  to try the PRNGD socket first, then if it's not there
or not answering, run the "internal" entropy collection code.  Then we
wandered into a discussion about whether or not OpenSSH should even have
the ssh_prng_cmds, run them from sshd, maintain all that extra code, etc.
I've seen some good arguments for and against it.  My preference is close
to what Dan has suggested for the order of where sshd should look when
trying to get some random bits:

1) Try /dev/[u]random.
2) Try PRNGD.
3) Try an improved "internal entropy collection" method that doesn't
involving running commands for each client connection.

I don't know exactly how /dev/urandom or PRNGD work, so I don't know if
it's possible to tell whether they're running and listening, or out of
entropy, or just not answering... in a timely enough manner to decide to
"punt" and run some commands.

Sure, we can sit back and say: "Pester Sun for a /dev/[u]random!"... but
there are way too many Sun/Solaris boxes out there in production, and Sun
is not making a /dev/[u]random for Solaris 2.x < Sol9 - that seems pretty
clear.  Maybe some day when we have upgraded all the production boxes to
Sol10 (Solaris 8+ doesn't run on older machines tho'), THEN we can just
use /dev/[u]random for OpenSSH.  Until then, the ANDIrand solution doesn't
run on just ANY version of Solaris, and that IMO is worse than a stock
Solaris ssh_prng_cmds file.

PRNGD is a nice tool and a "good" solution for Solaris - but you still
have to worry about making it run the right set of commands, just like in
the ssh_prng_cmds file with the internal entropy collection of OpenSSH.
It'd be nice to improve the internal routines... for those who don't have
the luxury of upgrading to the latest OS version or ditching the old
hardware or whose vendor won't backport /dev/[u]random to it's older OS
versions...

	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