Hello, this is my first post to this list. I'm a software developer. The product line I'm developing indirectly uses OpenSSL through a 3rd party library. Specifically, the library does a decryption of a license file right at the startup of our application. Trouble is, the OpenSSL startup is taking over 1 second on a modern computer running Windows 8.1 x64. 1 second doesn't sound like much, but that's time our user has to wait every time to see our user interface. The entire rest of our startup logic literally takes a few tens of milliseconds. It's making our application sluggish, and we need the license file verified before the application starts up. We tracked the delay down to OpenSSL's entropy gathering heap walking logic in the RAND_poll() function in rand_win.c. The Heap32First() and Heap32Next() Windows API calls are monstrously inefficient - each iteration taking a significant part of a second just to return a pointer to the first or next heap entry. Since the logic attempts to walk through the entire heap, it doesn't take many calls at all to exceed the MAXDELAY time of 1000 milliseconds (one full second). I have the impression, looking at the RAND_poll() code, that the MAXDELAY of 1000 milliseconds is a "watchdog" timeout meant to prevent a complete lockup under some unspecified condition, and it is not expected to be exercised in the normal case. Researching a bit further, MAXDELAY appears to have been added to RAND_Poll() some 5+ years ago. As a source of entropy, the number of bytes that COULD be "added" together by RAND_add() in the heap walking loop should be monstrous - millions or even billions. But in practice that's just not happening, since it's taking so long to get the pointers. It literally can just be a few thousands of bytes. So... Two things: 1. Since Heap32First() and Heap32Next() move glacially, not very many heap blocks are traversed in 1000 milliseconds (possibly only one or a handful on an average computer). This implies the heap walking loop is a VERY poor source of entropy given the amount of CPU time spent. I'm no expert on entropy, but this appears to reduce the security of the library. 2. The library in our case is being used in a client application where (unlike a server that starts OpenSSL up once and stays up) it's initialized every time the application is opened, and so the startup time is important. Can the watchdog timeout for the heap walk loop be reduced to something more reasonable? Say 100 milliseconds? It's pretty clear that if a more efficient method is implemented to walk through heap blocks, a LOT more entropy can be gathered in a LOT less time. Bear in mind also that computers are a LOT faster than they were even 5 years ago when the 1 second MAXDELAY timeout was first implemented. If need be, I can likely put together source code to accomplish the above. Thanks. -Noel Carboni ProDigital Software -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150118/18a6d94c/attachment.html>
