[openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Joey Yandle via RT]

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT" <rt at openssl.org> wrote:

> This message is to the OpenSSL source code maintainers via
> rt at 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
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted