openssh unix dev - Nov 2001 - Entropy and DSA key

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

On Tue, Nov 06, 2001 at 03:03:10PM -0500, Ed Phillips wrote:
> 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.
What I like about this suggestion is the basic notion of *redundancy*. We've
been using the internal commands for OpenSSH in part because that's the 
default config, and in part because the idea of relying on 'prngd' or 
'egd.pl' to be up & running properly for a critical service like SSH
is
frightening (from a single point of failure to multiple points of failure). 
I'd like to be able to specify something like
 - try /dev/urandom if it exists
 - else try egd's pool
 - else fall back on prngd's pool
 - else fall back on ssh_prng_cmds

Obviously this is mainly a problem with OSes like Solaris that do not
provide kernel-based random data sources that we can rely on.

It would be nice to specify different pools (or lists of pools) for sshd vs. 
the client applications, and it would be nice for users to be able to 
specify their own pools for their clients. Reasons being
 1) I prefer that true entropy sources like /dev/random not be world-accessible
 2) Some users may be granted access to such sources (e.g. wheel group)
 3) On some system (e.g. shell accounts) users may want to use better 
    entropy sources for their clients than the system admin has specified
    (e.g. /dev/urandom instead of ssh_prng_cmds)

Thanks to all (especially those helping me off-list),

-Peter