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



-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:richard@levitte.org]
Sent: Monday, 4 April 2005 5:17 PM
To: openssl-dev@openssl.org; smr@essemer.com.au
Subject: Re: How good a random source is Crypto API?

In message <200504040653.j346rRVU006784@mail09.syd.optusnet.co m.au> on Mon,
4 Apr 2005 16:53:21 +1000, "Steven Reddie" 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?


Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

Richard Levitte 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 majordomo@openssl.org