Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Analysis of OpenSSL's Random Number Generator

eprint.iacr.org

Post reply on HN
Print view View original

11–20 of 37 posts

Re: An Analysis of OpenSSL's Random Number Generator

#11

Post by slavik81 »

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/

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances.

> Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

Re: An Analysis of OpenSSL's Random Number Generator

#12

Post by erichurkman »

rootw0rm wrote: post #9
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.

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

Re: An Analysis of OpenSSL's Random Number Generator

#13

Post by miles »

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…

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

Re: An Analysis of OpenSSL's Random Number Generator

#14

Post by geofft »

slavik81 wrote: post #11
anaphor wrote: post #7

Earlier quoted context omitted.

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

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances. > Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

One of the very early initscripts (on Debian, /etc/rcS.d/urandom or /lib/systemd/system/urandom.service, both of which happen well before normal initscripts) restores a random seed that was saved at last shutdown.

After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swap -- so if you're writing code that needs to run there, you hopefully know that the system is in a weird state. And if you're writing something that runs a service that needs secure random numbers that early in the boot process, you're definitely doing something nonstandard and possibly misguided, and it's reasonable for the burden to be on you to take appropriate precautions, or switch to doing something normal.

For normal application developers, who tend to wait until after the network is up to interact with the network, this special case doesn't apply.

Re: An Analysis of OpenSSL's Random Number Generator

#15

Post by geofft »

miles wrote: post #13
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…

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

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

Re: An Analysis of OpenSSL's Random Number Generator

#16

Post by slavik81 »

geofft wrote: post #14
slavik81 wrote: post #11

Earlier quoted context omitted.

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances. > Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

One of the very early initscripts (on Debian, /etc/rcS.d/urandom or /lib/systemd/system/urandom.service, both of which happen well before normal initscripts) restores a random seed that was saved at last shutdown. After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swa…

The usual time I've been concerned has been after creating a new virtual machine. Right after creating a new DO droplet I need to do a bunch of things to set up my application, like seed my CSRF token generator.

Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.

Re: An Analysis of OpenSSL's Random Number Generator

#17

Post by dchest »

rootw0rm wrote: post #8

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.

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

Re: An Analysis of OpenSSL's Random Number Generator

#18

Post by geofft »

slavik81 wrote: post #16
geofft wrote: post #14

Earlier quoted context omitted.

One of the very early initscripts (on Debian, /etc/rcS.d/urandom or /lib/systemd/system/urandom.service, both of which happen well before normal initscripts) restores a random seed that was saved at last shutdown. After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swa…

The usual time I've been concerned has been after creating a new virtual machine. Right after creating a new DO droplet I need to do a bunch of things to set up my application, like seed my CSRF token generator. Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.

Ugh, yes, the practice of short-lived machines throws off the assumption of "when it was last shut down." You are totally right that this is a concern.

The ideal solution to this would be for hypervisors to just pass a random seed to their guests. (There is even a full virtio-rng device in qemu, it just seems to have /dev/random semantics from a quick glance.) I don't know how we get to the point of convincing the big cloud providers to start doing this, though.

Re: An Analysis of OpenSSL's Random Number Generator

#19

Post by technion »

slavik81 wrote: post #11
anaphor wrote: post #7

Earlier quoted context omitted.

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

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances. > Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

The part of this myth is down to what those circumstances are.

What's generally accepted is that, early during first boot, urandom still produces 'random' data without enough entropy for it to be sufficiently random.

What's a myth is that 'entropy can run out' and somehow a sufficiently seeded CSPRNG needs to block after a few reads while it gathers more entropy.

The problem in these discussions is that one, edge case, but valid concern, becomes a cargo cult of "why you shouldn't use urandom" and introduces a messy anti-pattern.

Re: An Analysis of OpenSSL's Random Number Generator

#20

Post by plaguuuuuu »

zer01 wrote: post #6

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

that sounds unsafe
Post reply on HN