Entropy and DSA key

[Ed Phillips]

On Tue, 6 Nov 2001, Dave Dykstra wrote:

> Date: Tue, 6 Nov 2001 10:39:37 -0600
> From: Dave Dykstra <dwd at bell-labs.com>
> To: Lutz.Jaenicke at aet.TU-Cottbus.DE
> Cc: openssh-unix-dev at mindrot.org, mouring at etoh.eviladmin.org,
>      Ed Phillips <ed at UDel.Edu>, Dan Astoorian <djast at cs.toronto.edu>
> Subject: Re: Entropy and DSA key
>
> On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote:
> > I don't see yet, in how far a "one shot" prngd would be different from
> > the internal entropy collection code.
>
> It would be the virtually the same but the advantage is it would only have
> to be maintained in one place.
>
> > It does cause a delay until enough
> > entropy was gathered. Granted, it would allow for a cleaner implementation
> > than having the code built-in, but for understandable reasons collecting
> > entropy requires the effort to collect the entropy :-)
>
> > Using a seed-save file helps, but somebody could steal it, so that calling
> > external gatherers at the time the cryptographic routines are started up
> > is an important issue.
>
> I don't buy that argument.  If somebody has the ability to steal your
> seed-save file, that means your system has already been compromised so I
> don't see the point of trying to secure it further, certainly not at such a
> high cost of time spent on every ssh client startup.  I think the only
> thing to worry about is an external attacker.

Well put.  I agree.  Sometimes, in all the security "hub-bub" I think
people fail to realize some of these simple things.  For anyone who has
slower, older systems to support (we only have approximately 100 Suns
ranging from SS1+ to 6800), the fact that ssh takes 2 minutes instead of 5
seconds has immense system administrative ramifications.  For example, if
you want to change the root password on every system - get ready to spend
the whole weekend...

It seem like most of the resistance to the whole internal entropy
collection thing is mainly the lack of interest in continuing support for
it... as opposed to any real deficiency (that wasn't designed in).  It
could be better.  Then, OpenSSH wouldn't rely on yet another 3rd party
package - for such a basic "you can't even get started without dealing
with this" need.  Sure, it makes supporting OpenSSH harder (more code =
more work = more user questions, etc.), but it makes it easier for the
user who doesn't have to go track down the other software, get it working
on their system, figure out how to make ssh use it... and then still
question the OpenSSH list about its use with OpenSSH specifically.  And
that in turn creates more "work", not "code" work, but still support work
nonetheless for those wonderful people that try to support OpenSSH.

For anyone who's used ssh-1.2.x, OpenSSH is nicer, but it's also worse in
this particular respect - the darn thing is unusable until you get over
the stupid entropy "hurdle", which never had to be dealt with in
ssh-1.2.x.

Dave mentioned in a previous email that he hasn't been able to find any
information stating that ssh-1.2.x was deficient due to it's entropy
collection scheme - which doesn't involve running 50 commands for every
client that connects.  Does anyone have hard evidence stating that the
ssh-1.2.x scheme is in fact, scientifically, deficient?

Thanks,

	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