This is a discussion on Re: RAND_egd() blocking -- despite contract that states otherwise? - Openssl ; On Fri, Nov 7, 2008 at 3:56 PM, Kyle Hamilton wrote: > 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 ...
On Fri, Nov 7, 2008 at 3:56 PM, Kyle Hamilton
> 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?
That's a great question. Indeed, this platform (AIX) does have /dev/random
but apparently that too was exhausted because that is checked first in our
implementation. I think the fault is truly with the system in question,
because prngd should not have blocked in the manner it did. Despite this
problem being a one-off, there is a push to "fix" the issue and guarantee it
will never happen again. It was during my investigations that I noticed the
blocking nature of the EGD lookups.