On Fri, Nov 7, 2008 at 4:56 PM, Kyle Hamilton <[EMAIL PROTECTED]> 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 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 still common. 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? -- Deron Meranda ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
