ssh-rand-helper

[Dan Astoorian]

On Tue, 22 Jan 2002 15:47:23 EST, Dave Dykstra writes:
> > - would it be desirable to make it possible for ssh-rand-helper to fall
> >   back to external commands if PRNGD cannot be reached, instead of
> >   choosing one or the other at compile time?
> 
> Ben said we should use OpenSSL's interface into PRNGD (at least the socket
> mode) instead and let ssh-rand-helper do running of commands.  I think that
> makes sense.  I first learned about RAND_egd() from you so I know you are
> familiar with it, but I finally got a chance to try it recently and I think
> it's a good way to go.

Now that djm has finally managed to fumigate the entropy-gathering cruft
from entropy.c, I fear he might be reluctant to let RAND_egd() calls
back into it.

Older releases of OpenSSL don't have RAND_egd(), which is presumably the
reason why the code to connect to it exists in ssh-rand-helper.c.

Furthermore, OpenSSL has no analog to PRNGD_PORT (PRNGD via TCP), so
ssh-rand-helper has to support PRNGD in some form in any case.

Personally, I think the ideal would be something like
    if OpenSSL-version >= 0.9.5 (i.e., RAND_egd() exists)
	include RAND_egd(PRNGD_SOCKET) calls in entropy.c
	omit PRNGD_SOCKET code in ssh-rand-helper.c
    else
	use existing PRNGD_SOCKET code in ssh-rand-helper.c

at configure-time.

> I don't see any.  I thought it was peculiar for ssh-rand-helper to link
> with OpenSSL at all, PRNGD doesn't.

PRNGD has its own secure hash algorithm (SHA borrowed from mhash-0.8.5).
Since OpenSSH already depends on OpenSSL, it makes much more sense to
link against it rather than adding hashing code to ssh-rand-helper.

I don't see any need for a hash algorithm if random bytes are being
retrieved from PRNGD, but making use of command outputs etc. would still
require one.

> I'm thinking I'll write a patch for PRNGD to have an option to be the
> ssh-rand-helper.   I also want it to skip the long "stir_from_commands"
> if the seedfile is valid.

Notwithstanding your reasonable arguments for why the seedfile should be
entirely sufficient, I'm reluctant, merely out of conservatism, to go
that far.

At the very least, I'd want to insist that the definition of "the
seedfile is valid" includes "a new seedfile was successfully written,"
because I can't prove that using the same seedfile more than once in
conjunction with the pittance of entropy provided by stir_from_system()
would be safe from a cryptoanalytical standpoint.

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