This message is to the OpenSSL source code maintainers via r...@openssl.org:
I reported this a while back and no one has seen fit to fix it. On Windows, the RAND_poll() function in the OpenSSL library uses ancient Heap32First and Heap32Next function calls to enumerate heap entries from all processes, because presumably this is considered to be a good source of entropy. Unfortunately, these specific methods, because of things that have been changed in Windows since the original design of the OpenSSL library, are now so tremendously inefficient that you are actually getting nearly zero entropy, as well as wasting a huge amount of computer time. We're measuring the time to get to the VERY FIRST check of the MAXDELAY operation - i.e., exactly ONE heap block has been read - as over one half second, and that's on a fast machine! The reason is described clearly here: https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023 In short, on a Windows 7 or newer system OpenSSL is spending a full second before the timeout occurs gathering one or maybe a very few heap blocks to contribute a few bytes of entropy to the random seed. What that article says is that the Heap32First and Heap32Next are NO LONGER VALID FUNCTIONS on Windows to be used for the purpose of gathering entropy! You're not really walking many entries at all and thus you are not getting the entropy you think you are. Various software packages use your library and expect it to initialize its own random seed effectively, which it is NOT doing. Instead, it's spending a full second spinning Windows' wheels behind the scenes and quite possibly even disrupting other operations, for ALMOST NO BENEFIT in entropy gathering. I cannot stress this enough. If you believe this should be worked-around by seeding the library directly, or by building an alternate copy of the library oneself, please bear this in mind: Not everyone who ultimately uses OpenSSL has control over how OpenSSL is being initialized. Imagine, for example, that the OpenSSL library is embedded in another, higher-level library, and that the product using the higher-level library has NO DIRECT EXPOSURE to OpenSSL. This, in fact, is the case with our own software. Every startup of our software, which we expect to be interactive, takes MUCH longer than it should - a significant portion of one second - because of this bug. Also, if you think that the MAXDELAY parameter should be shortened, that is not valid either. You should understand that even the first check of that timeout is delayed by a significant portion of a second! This needs to be fixed! -Noel Carboni ProDigital Software -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
