An Analysis of OpenSSL's Random Number Generator (opens in new tab)

(eprint.iacr.org)

77 pointsrandombit9y ago36 comments

36 comments

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

plaguuuuuu9y ago

that sounds unsafe

Natanael_L9y ago

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.

1 more reply

ryuuchin9y ago

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.

miles9y ago

"/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...

Just stumbled onto it in the new submissions queue:

https://news.ycombinator.com/item?id=11485876

geofft9y ago

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

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.

1 more reply

maxerickson9y ago

That article says //Continue filling with other sources where it should say //exit with an error.

neerdowell9y ago

/dev/urandom isn't reliable; it fails in a chroot, if file handles are exhausted, etc.

jjnoakes9y ago

It fails in a poorly set up chroot, not any old chroot.

It also fails in a poorly set up root file system in the same way. No chroot needed.

I can't remember ever running out of file descriptors unless a program had a leak. But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion.

A system call definitely has some minor benefits over a file in /dev, bit the reverse is also true (access from shells, or any language really, with no built in support).

But calling /dev/urandom unreliable is a little bit intellectually dishonest.

1 more reply

caf9y ago

Seeding a userspace CSPRNG from /dev/urandom or getrandom(2) is actually the right approach. The kernel pool is a resource shared among all processes, with the locking and therefore scalability constraints that implies.

KMag9y ago

Also, it's a good idea to reseed your userspace CSPRNG from the kernel's entropy source periodically. This is precisely what OpenBSD did with their arc4random and arc4random_buf library calls. (Don't worry, they now use ChaCha20 instead of arcfour/RC-4, but have kept the function name unchanged, since it's a backward-compatible change... the only way a caller can tell RC-4 from ChaCha20 is by detecting small statistical biases in RC-4's outputs.)

cyphar9y ago

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.

anaphor9y ago

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

2 more replies

ryuuchin9y ago

No I definitly mean /dev/urandom[1] or the getrandom syscall which would be equal to /dev/urandom.

[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

rootw0rm9y ago

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.

erichurkman9y ago

Isn't 'semi-broken' equal to 'broken' for cryptographic purposes?

RRRA9y ago

Are any OpenSSL fork vulnerable in the same way?

Titanous9y ago

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

https://boringssl.googlesource.com/boringssl.git/+/refs/head...

https://github.com/libressl-portable/openbsd/blob/master/src...

rootw0rm9y ago

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.

dchest9y ago

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

ICallsBS9y ago

10^9 out of 10^25 different combinations is a significant sample size? Wouldn't the law of small numbers apply in this case?

j / k navigate · click thread line to collapse

36 comments

zer019y ago

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

plaguuuuuu9y ago

that sounds unsafe

Natanael_L9y ago

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.

1 more reply

ryuuchin9y ago

miles9y ago

"/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...

Just stumbled onto it in the new submissions queue:

https://news.ycombinator.com/item?id=11485876

geofft9y ago

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

1 more reply

maxerickson9y ago

That article says //Continue filling with other sources where it should say //exit with an error.

neerdowell9y ago

/dev/urandom isn't reliable; it fails in a chroot, if file handles are exhausted, etc.

jjnoakes9y ago

It fails in a poorly set up chroot, not any old chroot.

It also fails in a poorly set up root file system in the same way. No chroot needed.

A system call definitely has some minor benefits over a file in /dev, bit the reverse is also true (access from shells, or any language really, with no built in support).

But calling /dev/urandom unreliable is a little bit intellectually dishonest.

1 more reply

caf9y ago

KMag9y ago

cyphar9y ago

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.

anaphor9y ago

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

2 more replies

ryuuchin9y ago

No I definitly mean /dev/urandom[1] or the getrandom syscall which would be equal to /dev/urandom.

[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

rootw0rm9y ago

erichurkman9y ago

Isn't 'semi-broken' equal to 'broken' for cryptographic purposes?

RRRA9y ago

Are any OpenSSL fork vulnerable in the same way?

Titanous9y ago