This is fixed in 1.1. On Jul 5, 2016 11:29 AM, "Noel Carboni via RT" <r...@openssl.org> wrote:
> 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 >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev