An Analysis of OpenSSL's Random Number Generator

Reminds me of one of my favorite commit logs from the LibreSSL project:<p>&quot;Do not feed RSA private key information to the random subsystem as entropy. It might be fed to a pluggable random subsystem…. What were they thinking?!&quot;<p><a href="http:&#x2F;&#x2F;opensslrampage.org&#x2F;post&#x2F;83007010531&#x2F;well-even-if-time-isnt-random-your-rsa" rel="nofollow">http:&#x2F;&#x2F;opensslrampage.org&#x2F;post&#x2F;83007010531&#x2F;well-even-if-time...</a>

I can&#x27;t understand Why OpenSSL continues to use it&#x27;s own PRNG implimentation when we have &#x2F;dev&#x2F;urandom and CryptGenRandom which are known to be good. This is basically what BoringSSL does (although if you have rdrand then it will get filtered through a ChaCha20 instance).<p>I&#x27;m pretty sure OpenSSL doesn&#x27;t even reseed its PRNG on Windows unless the calling application does it so I&#x27;m not sure how that&#x27;s safe either. If you look at applications using OpenSSL like OpenVPN I don&#x27;t see any calls to the PRNG init function to ensure it has enough entropy. I&#x27;m not sure of the security impact of this.

Are any OpenSSL fork vulnerable in the same way?

I actually have several TB of OpenSSL PRNG output (256 bit len) that I&#x27;ve been analyzing. A fairly modest sample size, but I&#x27;ve come across some interesting patterns at the bit level. It&#x27;s kind of a pain in the ass to write efficient analytics for a binary 256 bit pattern as a matter of fact.