Entropy and DSA key

Dan Astoorian djast at cs.toronto.edu
Wed Nov 7 06:06:41 EST 2001


On Tue, 06 Nov 2001 13:21:02 EST, Dave Dykstra writes:
> On Tue, Nov 06, 2001 at 01:08:43PM -0500, Dan Astoorian wrote:
> > 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.
> 
> I was with you until that point.  It's essential for me that the seed file
> be able to be kept per user because I have no way of installing a
> privileged program on most of the computers in my distribution.  This is the
> way ssh 1.2.27 did it.

That's not the situation for most users.  I don't know many people who
can install sshd without at least some administrative privileges.

BTW, "privileged program" need not imply "setuid-root"; the seed file
could belong to a dedicated non-root user, and the program setuid to
that user.  There are pros and cons to having PRNGD run as root, which I
won't get into; suffice it to say I've suggested to Lutz in the past
that it would be a useful feature if PRNGD could be configured to
rescind root privileges after binding to its socket, and he says it's on
his to-do list for PRNGD.

For the general case, I stand behind my proposed design.  Cases such as
Dave's would require compromises, such as an entropy-client which could
run unprivileged, and an OpenSSL that was configured to look in a
non-standard location for the PRNGD socket (since an unprivileged PRNGD
couldn't bind to /var/run/entropy or the other standard locations), etc.
Such tweaks aren't a big deal.

My questions are whether my proposed design as a whole is sound,
practical, and implementable, whether anyone can suggest improvements to
it, and whether any of the developers for all of the projects involved
(OpenSSL, OpenSSH, and PRNGD) like these ideas enough to get together
and implement any of them.  :-)

-- 
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



More information about the openssh-unix-dev mailing list