Entropy and DSA key

[Dan Astoorian]

On Tue, 06 Nov 2001 11:23:36 EST, Lutz Jaenicke writes:
> 
> I don't see yet, in how far a "one shot" prngd would be different from
> the internal entropy collection code. 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 :-)

A cleaner implementation is a worthwhile goal.

There should be a method of gathering entropy available which will, to
the degree that it's possible, always work.  OpenSSH's (or OpenSSL's)
interface to that method should be as clean as possible; a command which
produces the entropy on stdout would seem to be the most obvious and
flexible implementation for such a method.

I think the ideal would be to see the problem addressed in OpenSSL
rather than in OpenSSH.  It already uses /dev/random if it's available,
and the next version will look for an EGD/PRNGD socket in a number of
"standard" locations.  It might make sense if OpenSSL could run a
command as a last resort.

A huge advantage of a "one-shot" invocation of prngd would be that such
a command would have all of the same sources of entropy available as
prngd itself (including such resources as seed files, which should be
stirred regularly during prngd's normal course of operation).  It adds
robustness, at the cost of efficiency but not the cost of substantially
poorer entropy.  Moreover, OpenSSH would no longer have to keep its own
seed file--and this circumvents the NFS issue, among others.

In summary, the way I'd like to see things is:
    - OpenSSH: doesn't need to do *anything* explicit to seed OpenSSL's
      PRNG
    - OpenSSL: tries, in order:
	a) /dev/[u]random
	b) connecting to PRNGD
	c) running an entropy-gathering program--let's call it
	"entropy-client"
    - PRNGD: operates much as it does now (but rewrites its seed file
      more often)
    - entropy-client: if PRNGD isn't running, runs the same programs
      PRNGD would to get its entropy (albeit less efficiently), mixes in
      and perturbs the same seed file.

Note that "entropy-client" would have to be a privileged program, since
the seed file is sensitive.  Managing the seed file is important: you
don't want to have a situation where the method you fall back to does
not have good entropy because that method is seldom used, and this is
why I think PRNGD and the one-shot command should be working together.

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican