On Fri, Feb 24, 2012 at 4:08 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 2/24/2012 2:14 PM, sandeep kiran p wrote: >> >> You mentioned that OpenSSL is holding a "snapshot" lock in rand_win.c. I >> couldn't find anything like that in that file. Can you specifically point me >> to the code that you are referring to? I would also like to get an opinion >> on possible workarounds that I can enforce to avoid the deadlock. >> > In OpenSSL 1.0.0 it is line 486 which says > > module_next && (handle = snap(TH32CS_SNAPALL,0)) > > where snap is a pointer to KERNEL32.CreateToolhelp32Snapshot() I've found that creating too many tool tip snapshots too frequently causes problems (in a different problem domain). How frequently is OpenSSL doing it? Just once during module startup? From where is it being called (it can't be DllMain)?
If the heap walk occurs once after DllMain, there should not be any problems (in theory). >> 1. Can I remove the heap traversal routines Heap32First and Heap32Next? >> Will it badly affect the PRNG output later on? > > It depends how good the other sources of random numbers are, > more below. >> >> >> 2. Can I replace Heap32First and Heap32Next calls with any other sources >> of entropy? What if I make a call to CryptGenRandom again in place of the >> heap traversal routines? > > Calling CryptGenRandom() twice isn't going to help much. > > If CryptGenRandom() is as good as it is "supposed to" be, > the other entropy sources are not really needed. But if > CryptGenRandom() is somehow broken or untrustworthy, > calling it a million times wouldn't help. "Cryptanalysis of the Random Number Generator of the Windows Operating System," eprint.iacr.org/2007/419.pdf > > [SNIP] > Also of interest might be "Analysis of the Linux Random Number Generator," eprint.iacr.org/2006/086.pdf. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
