Re: heap walk in rand_win.c is quite slow
Jeffrey Altman writes: > Suggestion. Do not wait until you establish your first connection to > call RAND_poll(). Initializae the PRNG as part of the startup of your > app or in a background thread. Yes; I have already done this, and it helps, but this is just a band-aid. The bottom line is, I'd rather not have to pay a 15-second penalty *anywhere* in my app if there's not a good reason for it; and there doesn't appear to be a good reason for this one. Is it even necessary to do the heapwalk at all? Since it is so very slow, especially with respect to all the other ways to gather entropy in the system, perhaps it should be replaced with some other mechanism, much faster but equally effective. For instance, if we could obtain the start and end of the range of valid readable addresses, we could sample a random word from within this range, and use that value to determine the address of the next random word within the range, and so on, for n cycles. David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: heap walk in rand_win.c is quite slow
Suggestion. Do not wait until you establish your first connection to call RAND_poll(). Initializae the PRNG as part of the startup of your app or in a background thread. > Greetings. > > The first SSL connection in my application was taking some 10 to 16 > seconds to return. Thereafter, subsequent SSL connections would > complete and return immediately. > > I eventually traced the culprit to RAND_poll() in rand_win.c. > Specifically, it was the part of RAND_poll() that walks through the > list of allocated blocks on the heap(s); this heap walk was consuming > almost all of those 16 seconds. > > I do have a large application, and there were no doubt several heaps, > each with many allocated blocks. I see that there was code in place > to limit the number of blocks traversed per heap to 50, but there was > no limit on the number of separate heaps that may be traversed. In > fact, it was visiting some 500 blocks total in my case. > > (The limit of 50 blocks per heap was as of version 0.9.6d. I note > that by 0.9.7-beta3 someone has upped that limit to 80, worsening my > problem.) > > Is it really necessary to visit so many blocks? I put in a quick hack > to apply the 50-block limit to the total number of blocks, rather than > per heap; this makes it take maybe 2 to 3 seconds instead, which is > still pretty slow but at least it's tolerable. (Apparently the > heap-walking routines in Win2000 are quite slow.) I am concerned that > someone recently felt the need to raise the count to 80, however. > What affect will capping this number have on the security of my > transactions? > > Perhaps the limit was originally meant to apply to the total number > anyway, and this was just an oversight? It doesn't make a whole lot > of sense to limit the number of blocks visited per heap, without also > limiting the number of heaps. > > Do you have any advice? > > Many thanks, > David > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
heap walk in rand_win.c is quite slow
Greetings. The first SSL connection in my application was taking some 10 to 16 seconds to return. Thereafter, subsequent SSL connections would complete and return immediately. I eventually traced the culprit to RAND_poll() in rand_win.c. Specifically, it was the part of RAND_poll() that walks through the list of allocated blocks on the heap(s); this heap walk was consuming almost all of those 16 seconds. I do have a large application, and there were no doubt several heaps, each with many allocated blocks. I see that there was code in place to limit the number of blocks traversed per heap to 50, but there was no limit on the number of separate heaps that may be traversed. In fact, it was visiting some 500 blocks total in my case. (The limit of 50 blocks per heap was as of version 0.9.6d. I note that by 0.9.7-beta3 someone has upped that limit to 80, worsening my problem.) Is it really necessary to visit so many blocks? I put in a quick hack to apply the 50-block limit to the total number of blocks, rather than per heap; this makes it take maybe 2 to 3 seconds instead, which is still pretty slow but at least it's tolerable. (Apparently the heap-walking routines in Win2000 are quite slow.) I am concerned that someone recently felt the need to raise the count to 80, however. What affect will capping this number have on the security of my transactions? Perhaps the limit was originally meant to apply to the total number anyway, and this was just an oversight? It doesn't make a whole lot of sense to limit the number of blocks visited per heap, without also limiting the number of heaps. Do you have any advice? Many thanks, David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
