ssh-rand-helper

Damien Miller djm at mindrot.org
Wed Jan 23 12:15:22 EST 2002


On Wed, 2002-01-23 at 10:59, Dan Astoorian wrote:
> On Tue, 22 Jan 2002 18:10:58 EST, Damien Miller writes:
> > 
> > I'd rather see some way to configure OpenSSL do fetch entropy from EGD
> > within the library itself. Currently it does this from /dev/urandom if
> > it is detected at compile time, so it isn't too great a step.
> 
> OpenSSL 0.9.7 (according to their website) will do this, if the socket
> is where the library expects it to be; i.e., /var/run/egd-pool,
> /dev/egd-pool, /etc/egd-pool or /etc/entropy.
> 
> However, I don't want the socket to live in any of those locations on my
> systems, because I don't run it with enough privileges to bind() in
> /var/run, /dev, or /etc.  I might change my mind if and when an option
> is added to PRNGD to give away root privileges after initialization.

Perhaps you could prevail on the OpenSSL developers to allow run-time
socket selection through an environment variable or similar? 

> 3) If RAND_egd() is available, using it in entropy.c instead of forking
>    ssh-rand-helper is an obvious and unobtrusive optimization--literally
>    one line of code ("if (!RAND_status()) RAND_egd(PRNGD_SOCKET)"), with
>    an #ifdef around it.  I would not be suggesting this might be done in
>    entropy.c if it were not so utterly trivial.

I'd prefer to keep entropy.c as minimal as possible - I certainly don't
want it depending on compile-time configured paths or ports. One of the
aims of splitting out ssh-rand-helper was to remove these from the core
code. In any case, a fork+exec+socket+connect+read+write+exit is hardly
an overhead to worry about.

> > RAND_egd doesn't support fetching from a localhost socket either, at
> > least not in my version of OpenSSL.
> 
> (I believe I mentioned that, actually.)

(sorry - I just skimmed your message in the brief time between breakfast
and work)

> I'm still interested in opinions about my original question, which was
> whether changing ssh-rand-helper to be able to support at build time
> both PRNGD and stir_from_commands() etc. simultaneously would be
> welcome.

I am considering that, and if you look at the recent revisions to
ssh-rand-helper.c you'll see that the code has been restructured to make
this a more simple change. But I _really_ don't like the command hashing
business and would much rather see it go in favor of an properly
maintained (by someone else!) Yarrow implementation.

-d





More information about the openssh-unix-dev mailing list