This is a discussion on Re: RAND_egd() blocking -- despite contract that states otherwise? - Openssl ; On Fri, Nov 7, 2008 at 4: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 4: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".
The EGD protocol does not define any way for this to be passed
back directly. You can make a specific EGD call to get the amount
of random data immediately available (which is loosely related to
the amount of entropy), but by the time you make a second call to
actually get the random data things could have changed.
But you shouldn't really care about the amount of entropy anyway.
You're necessarily trusting the EGD daemon to only return
suitably random data, not second guess its internal entropy.
However the EGD protocol does define TWO methods of getting
data; one "blocking" and one "non-blocking". This is not
blocking in terms of traditional Unix I/O; but in terms of waiting
around on entropy gathering when the entropy runs low. In the
blocking daemon mode; the daemon will not return any data until it
has gathered enough entropy to satisfy the number of bytes
requested. In the non-blocking mode, if it runs out of entropy
it will just return what little it does have, i.e., it may return
fewer bytes than requested (including possibly zero bytes).
What bytes it does return will be random, but you may just
not get as much as you requested.
Rather than messing around with timeouts and such, perhaps
OpenSSL should just make the non-blocking EGD call rather
than the blocking one. Then it will just have to deal with the
case where it may have gotten fewer bytes than it requested.
(Note that invoking the EGD non-blocking mode still uses
Unix-level blocking reads).
BTW, in the prngd implementation of EGD; the non-blocking
and blocking modes are equivalent. prngd will always be
able to satisfy the request (it never runs out of entropy).
> 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?
Most OSes by this point I think do provide random devices.
However older versions of those operating systems are still
in wide use. HP-UX I know was one of the very last to get a proper
/dev/random, so slightly older versions that don't have it are
Also, I don't know about any specialized or embedded OSes.
EGD support may still be needed for those.
I guess a separate question is why prngd was hanging. It is not
supposed to do that, regardless of the amount of entropy available.
There were some bugs in older versions though, and if I remember
right, some of those bugs were specific to AIX's peculiarities. What
version of prngd were you using Ben, and what version of AIX?
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org