This is a discussion on Re: RAND_egd() blocking -- despite contract that states otherwise? - Openssl ; 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 ...
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
On Fri, Nov 7, 2008 at 8:41 AM, Ben Sandee
> On Fri, Nov 7, 2008 at 9:38 AM, David Schwartz
>> Sounds like the interface is badly thought out. Perhaps the best
>> 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
>> 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.
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org