Hi Richard, I'm reasonably familiar with that code, having spent some time debugging it over the years. I've experienced the thread-safety issues (eg. walking the heap snapshot while threads are simultaneously being created/destroyed), slow performance with the same section of code, and the crash/hang I mentioned. I think I also experienced some additional NT4-specific problems some years ago.
I'm guessing that Microsoft figure that obscurity adds a little more security -- not to say they're relying on security-through-obscurity, but that if an implementation is secure and private it's possibly a little more secure than an implementation that is secure and public; at least I can understand why they think that. > Do you have an idea on how to make things more stable ... No, that's the problem, I don't see much of a way to make this code more secure when it's doing the kind of things that it is. When I say that some of the things that the code do are exotic, I mean that they're not usual operations performed by most applications out there and as such bugs involving those functions are less likely to be found and fixed -- the Lotus Notes uninstall for example produced an unstable environment but when no other applications are exercising that functionality then it's less likely to be found; I doubt the customer cared too much when we told them it was a poor Lotus Notes uninstall, to them it was our application that wouldn't function after install. I have a suspicion that the thread-safety could be improved by doing the heap walking in DllMain (which I believe to be called in a single-threaded mannor) but putting such a mechanism into OpenSSL that would also be used by DLLs that link in the static library build of OpenSSL isn't straight-forward. Regards, Steven -----Original Message----- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED] Sent: Monday, 4 April 2005 5:17 PM To: openssl-dev@openssl.org; [EMAIL PROTECTED] Subject: Re: How good a random source is Crypto API? In message <[EMAIL PROTECTED]> on Mon, 4 Apr 2005 16:53:21 +1000, "Steven Reddie" <[EMAIL PROTECTED]> said: smr> Moving such functionality out-of-process would improve stability, smr> and this is obviously where prngd/egd comes in, but if these are smr> seen as useful for more secure applications then it seems that a smr> default OpenSSL install could settle for CryptoAPI's PRNG. Except for the small matter of knowing what the seeding generator uses as sources. As was mentioned, Microsoft is very secretive about the sources used for CryptGetRandom(). prngd/egd are open source... BTW, OpenSSL does use the CryptoAPI PRNG *as well*, just FYI... I do understand the problem with crashing systems. Do you have an idea on how to make things more stable in that kind of situation, and still have a more varied set of randomness sources than just CryptoAPI? Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
