An Analysis of OpenSSL's Random Number Generator

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/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).

I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If you look at applications using OpenSSL like OpenVPN I don't see any calls to the PRNG init function to ensure it has enough entropy. I'm not sure of the security impact of this.

Re: An Analysis of OpenSSL's Random Number Generator

#5

Post by cyphar » Wed, Apr 13, 2016, 4:54 AM UTC

ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/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). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…

I think you mean /dev/random. On unixes, /dev/urandom produces a stream of random bytes that may not have high entropy, while /dev/random will block on reads until there's enough entropy in the pool.

Re: An Analysis of OpenSSL's Random Number Generator

#6

Post by zer01 » Wed, Apr 13, 2016, 4:59 AM UTC

Reminds me of one of my favorite commit logs from the LibreSSL project:

"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?!"

http://opensslrampage.org/post/83007010531/well-even-if-time...

Re: An Analysis of OpenSSL's Random Number Generator

#7

Post by anaphor » Wed, Apr 13, 2016, 5:00 AM UTC

cyphar wrote: post #5

ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/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). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…

I think you mean /dev/random. On unixes, /dev/urandom produces a stream of random bytes that may not have high entropy, while /dev/random will block on reads until there's enough entropy in the pool.

nope, that's a myth http://www.2uo.de/myths-about-urandom/

Re: An Analysis of OpenSSL's Random Number Generator

#8

Post by rootw0rm » Wed, Apr 13, 2016, 5:23 AM UTC

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

Re: An Analysis of OpenSSL's Random Number Generator

#9

Post by rootw0rm » Wed, Apr 13, 2016, 5:31 AM UTC

ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/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). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…

It depends upon which of the many functions you call to get your bits, iirc. I've been studying it a bit, though i've taken a little break, so i'd need to find my notes. it's certainly terrible on windows, but not completely broken...only semi-broken, lol. i think i remember there being some ancient reseeding mechanism that only works on XP in there somewhere too, but fuck it i'm drunk.

Re: An Analysis of OpenSSL's Random Number Generator

#10

Post by cyphar » Wed, Apr 13, 2016, 5:35 AM UTC

anaphor wrote: post #7

cyphar wrote: post #5

Earlier quoted context omitted.

I think you mean /dev/random. On unixes, /dev/urandom produces a stream of random bytes that may not have high entropy, while /dev/random will block on reads until there's enough entropy in the pool.

nope, that's a myth http://www.2uo.de/myths-about-urandom/

Interesting. I picked up that misconception from a Linux kernel comment a while ago. Thanks for telling me it's a myth. I knew that the two outputs came from the same source, I just assumed that the blocking had more-than-negligible effects.