openssh unix dev - Jan 2002 - ssh-rand-helper

Now that ssh-rand-helper has been segregated into a separate program,
I'd like to revisit an old question about its entropy gathering.

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

- When using PRNGD, the program gets 48 bytes of entropy from PRNGD,
  stirs it into OpenSSL's RAND_add(), and outputs 48 bytes of
  pseudorandom bytes based on this entropy.  Does this present any
  advantage over just dumping the 48 bytes of entropy received from
  PRNGD directly? 

The semantics I'm envisioning here:

    Define USE_PRNGD, USE_CMDS, or both.

    Case 1: USE_PRNGD && USE_CMDS:
      read_seedfile()
      fetch 96 bytes from PRNGD
      if successful
	output(bytes 1-48)
	RAND_add(bytes 49-96) /* for seedfile */
      Otherwise
	stir_from_commands()
	stir_from_system()
	output(RAND_bytes(48))

      write_seedfile()

    Case 2: !USE_PRNGD && USE_CMDS:
      read_seedfile()
      stir_from_commands()
      stir_from_system()
      output(RAND_bytes(48))
      write_seedfile()

    Case 3: USE_PRNGD && !USE_CMDS:
      fetch 48 bytes from PRNGD
      if successful
	output(bytes)

Note that the seedfile is always read and written if USE_CMDS is defined
even if the entropy comes from PRNGD, so that there's a good seedfile
available in case PRNGD goes away.

Would a patch (or rewrite) to implement this be welcome?

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

On Tue, Jan 22, 2002 at 02:45:08PM -0500, Dan Astoorian
wrote:
> Now that ssh-rand-helper has been segregated into a separate program,
> I'd like to revisit an old question about its entropy gathering.
A related topic has had some discussion on the secureshell at securityfocus.com
recently in the thread "Question on prngd and slow OpenSSH".

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

> - When using PRNGD, the program gets 48 bytes of entropy from PRNGD,
>   stirs it into OpenSSL's RAND_add(), and outputs 48 bytes of
>   pseudorandom bytes based on this entropy.  Does this present any
>   advantage over just dumping the 48 bytes of entropy received from
>   PRNGD directly? 
I don't see any.  I thought it was peculiar for ssh-rand-helper to link
with OpenSSL at all, PRNGD doesn't.

> The semantics I'm envisioning here:
> 
>     Define USE_PRNGD, USE_CMDS, or both.
> 
>     Case 1: USE_PRNGD && USE_CMDS:
>       read_seedfile()
>       fetch 96 bytes from PRNGD
>       if successful
> 	output(bytes 1-48)
> 	RAND_add(bytes 49-96) /* for seedfile */
>       Otherwise
> 	stir_from_commands()
> 	stir_from_system()
> 	output(RAND_bytes(48))
> 
>       write_seedfile()
> 
>     Case 2: !USE_PRNGD && USE_CMDS:
>       read_seedfile()
>       stir_from_commands()
>       stir_from_system()
>       output(RAND_bytes(48))
>       write_seedfile()
> 
>     Case 3: USE_PRNGD && !USE_CMDS:
>       fetch 48 bytes from PRNGD
>       if successful
> 	output(bytes)
> 
> Note that the seedfile is always read and written if USE_CMDS is defined
> even if the entropy comes from PRNGD, so that there's a good seedfile
> available in case PRNGD goes away.
> 
> Would a patch (or rewrite) to implement this be welcome?
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.

- Dave Dykstra

On Tue, 22 Jan 2002, Dan Astoorian wrote:
> > 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.
> 
> I only saw two mentions of ssh-rand-helper.c in the portable ChangeLog
> (your introduction of it on 12/22/2001 and Kevin's __progname change
> three days later), so I don't know what you mean by "recent
revisions,"
> sorry.  I just saw that, as of yesterday's snapshot, about 7/8ths of
> ssh-rand-helper.c is within the USE_PRNGD #ifdef-#else-#endif.
There may be some time skew between the late Australian evenings that
I commited the changes and the early Canadian mornings that the snapshots
are built. If you use anonCVS, then you should see all the changes.
> > 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.
> 
> Unfortunately, I don't currently have that kind of time and
> cryptographic expertise to throw at the problem, or I'd offer to do
> that.
> 
> I'm not familiar with Yarrow, and don't understand how any
algorithm
> could generate entropy without some genuine source of randomness to
> start from.  Isn't Yarrow just another PRNG, which still needs to be
> seeded with entropy from somewhere?
You are quite correct - Yarrow is just a system to maintain a 
cryptographic random number source. Some people have used it to build 
things like the command hashing part of ssh-rand-helper. The main
attraction is that it is purpose built and maintained by someone else.

-d

> You are quite correct - Yarrow is just a system to maintain a
> cryptographic random number source. Some people have used it to build
> things like the command hashing part of ssh-rand-helper. The main
> attraction is that it is purpose built and maintained by someone else.
"The generation of random numbers is far too important to be left to
chance."

--Dan

> You are quite correct - Yarrow is just a system to maintain a
> cryptographic random number source. Some people have used it to build
> things like the command hashing part of ssh-rand-helper. The main
> attraction is that it is purpose built and maintained by someone else.
"The generation of random numbers is far too important to be left to
chance."

--Dan