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