There should be some means of determining how much entropy is actually in the information obtained from the EGD. The return values should reflect the number of bits stirred in, with 0 being "we haven't gotten anything yet". Pass this up to the client library, and the client library should pass this back to the application so the app itself can figure out how to present it (and figure out if the app wants to do anything else before calling it again).
The EGD is only needed on a couple of platforms... and those platforms have had over a decade to get used to the idea of secure random numbers being necessary for a lot of information security applications. Why have they not yet created /dev/random and /dev/urandom drivers? -Kyle H On Fri, Nov 7, 2008 at 8:41 AM, Ben Sandee <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 9:38 AM, David Schwartz <[EMAIL PROTECTED]> wrote: >> >> Sounds like the interface is badly thought out. Perhaps the best >> "reasonable >> compromise", short of changing the interface, is to set a limit (maybe 3 >> seconds or so) to how long RANG_egd can block (this would mean it will >> have >> to call 'poll' or the like). Yucky to do portably. > > This may be a naive suggestion, but what about calling setsockopt() send and > receive timeouts to some value by default? I'm just not really a > networking-savvy guy so I don't know if this would be sufficiently > non-blocking for these purposes. In theory the prngd and/or EGD should not > be blocking (for a signficant time) ever according to their design specs. > > Ben > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
