On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <pravesh....@gmail.com> wrote: >> >> CryptGenRandom(hCryptProv, SEED_SIZE, buf); // On Windows OS >> apr_generate_random_bytes(buf, SEED_SIZE); // On Linux OS >> Speaking of poor documentation.....
I looked at the "header" and the "source". They are different "style sheets" applied to the same file (I expected to see the H file, and the C file). Neither had comments. Confer http://apr.apache.org/docs/apr/0.9/apr__general_8h-source.html and http://apr.apache.org/docs/apr/0.9/group__apr__random.html. I'll reproduce it here without the markup: apr_status_t apr_generate_random_bytes( unsigned char * buf, int length ) So, there are a few problems here. First is no documentation. Verbum sapienti sat. Second, you don't know what conditions need to be satisfied to define APR_HAS_RANDOM (did you even know it was there?). This could be fixed with documentation, but APR chose otherwise. Third, you don't know what the function returns on success. Is there a apr_succes? Or apr_true? This could be fixed with documentation, but APR chose otherwise. Fourth, the API tells you a negative length is acceptable. This could be fixed with documentation, but APR chose otherwise. A negative length makes no sense whatsoever (I know, its not limited to APR). I would encourage you to write a few negative self-tests and submit it to the project: send in a NULL`buf`, a zero `length`, and a negative `length`. See how the library handles it. Since they botched the API design, I would not be surprised if they SIGABRT on you (that's how *not* to build a resilient system). Fifth, there is probably some internal state, but we don't know that for sure. This could be fixed with documentation, but APR chose otherwise. If there is state, you don't know where it came from or its quality. Did they limit themselves to (1) Time of Day, (2) Mac address, (3) /dev/{u}rand, (4) the kernel's hwrand, or (5) virtio gear? Perhaps some other clever combination? Are they constantly hedging (probably not)? If there is no state, they have already broken you (that's how *not* to build a resilient system). This is a bit more personal taste, but I require PRNGs to be thread safe. So Sixth, is the library thread safe? Is the call to apr_generate_random_bytes() thread safe? I would definitely write a multithreaded self test and try to break it. I can email you a set if you need a canned test that spins up 64 threads (hit me off list). Headless servers, entropy starvation, and rollbacks are a concern in modern environments. OpenSSL and other entropy gathers, such as EDG, don't account for the later. Its best to take the bull by the horns and do it yourself. At minimum, you need to call RAND_add() with entropy external to /dev/{u}rand. The following may also be useful to you: * Analysis of the Linux Random Number Generator, eprint.iacr.org/2006/086.pdf * Cryptanalysis of the Random Number Generator of the Windows Operating System, eprint.iacr.org/2007/419.pdf Most recent analysis of Linux RNG (AFAIK): * Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices, https://factorable.net/paper.html Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
