
An Analysis of OpenSSL's Random Number Generator - randombit
https://eprint.iacr.org/2016/367
======
zer01
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...](http://opensslrampage.org/post/83007010531/well-even-if-time-isnt-
random-your-rsa)

~~~
plaguuuuuu
that sounds unsafe

~~~
Natanael_L
A hash of the private key isn't actually bad to use for entropy. It's what's
done in deterministic EC signatures, deriving the k value from the private key
+ message.

~~~
Natanael_L
As long as the hash function is strong, why exactly would this be weak?
Downvoting me implies you believe these people are wrong too;

[https://tools.ietf.org/html/rfc6979](https://tools.ietf.org/html/rfc6979)

> It is possible to turn DSA and ECDSA into deterministic schemes by using a
> deterministic process for generating the "random" value k. That process must
> fulfill some cryptographic characteristics in order to maintain the
> properties of verifiability and unforgeability expected from signature
> schemes; namely, for whoever does not know the signature private key, the
> mapping from input messages to the corresponding k values must be
> computationally indistinguishable from what a randomly and uniformly chosen
> function (from the set of messages to the set of possible k values) would
> return.

> d. Set: > K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1))

> where '||' denotes concatenation. In other words, we compute HMAC with key
> K, over the concatenation of the following, in order: the current value of
> V, a sequence of eight bits of value 0, the encoding of the (EC)DSA private
> key x, and the hashed message (possibly truncated and extended as specified
> by the bits2octets transform). The HMAC result is the new value of K. Note
> that the private key x is in the [1, q-1] range, hence a proper input for
> int2octets, yielding rlen bits of output, i.e., an integral number of octets
> (rlen is a multiple of 8).

------
ryuuchin
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.

~~~
miles
_" /dev/urandom and CryptGenRandom which are known to be good"_

Check out _" A good idea with bad usage: /dev/urandom"_:

[http://insanecoding.blogspot.com/2014/05/a-good-idea-with-
ba...](http://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-
devurandom.html)

Just stumbled onto it in the new submissions queue:

[https://news.ycombinator.com/item?id=11485876](https://news.ycombinator.com/item?id=11485876)

~~~
geofft
... I'm not sure I can take an article seriously that suggests "but what if
the attacker can modify files in /dev?".

In any case, the meaningful concerns from that article have been addressed
with the getrandom syscall on Linux, introduced a few months after this
article was written:
[https://lwn.net/Articles/606141/](https://lwn.net/Articles/606141/)

Perhaps we should start saying "getrandom" / "getentropy" instead of
"/dev/urandom", but they're the same underlying CSPRNG (although getrandom has
the distinct advantage of allowing you to tell if the urandom pool has been
initialized, which /dev/urandom doesn't let you do), so I can understand being
sloppy with usage. I would sort of assume anyone in a position to patch
OpenSSL's RNG either upstream or in a distro is aware of getrandom and why it
exists, but maybe that's a bad assumption.

~~~
ryuuchin
I forgot about the new getrandom syscall but yes that would be preferred if
supported.

------
RRRA
Are any OpenSSL fork vulnerable in the same way?

~~~
Titanous
No. Both BoringSSL and LibreSSL use substantially different (and safer)
systems for their CSPRNG.

[https://boringssl.googlesource.com/boringssl.git/+/refs/head...](https://boringssl.googlesource.com/boringssl.git/+/refs/heads/master/crypto/rand/rand.c)

[https://github.com/libressl-
portable/openbsd/blob/master/src...](https://github.com/libressl-
portable/openbsd/blob/master/src/lib/libc/crypt/arc4random.3)

------
rootw0rm
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.

~~~
dchest
That's numerology, you just have many outputs of SHA1 with different inputs.

