[openssl-users] Long startup time and poor entropy on Windows due to inefficient heap walking In RAND_poll()

[Noel Carboni]

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>