ssh-rand-helper

[Dan Astoorian]

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