Major upgrade to FreeBSD’s /dev/random | Hacker News Reader

random

svnweb.freebsd.org

110 pointslelf28 comments

Linux should adapt this work.

I've read Ted T'so dismissing the "/dev/urandom for everything camp" somewhere lately.

Together with his appearance here on HN, I very much doubt he's going to change his position anytime soon.

He thinks the criticism of Linux's random device is purely academic. Maybe he's right, he's certainly way better qualified than I am, but I'm still very unimpressed by how the Linux guys just dismiss any discussion for a changed random device.

Well, they implemented getrandom quickly. Let's take it as a promising sign.

It's very clear that /dev/urandom will never be changed in a way that it could possibly block; that is considered by T'so to be breaking userspace. I could possibly see /dev/random adopting the BSD behavior, but more likely everyone who cares will switch to getrandom, and it won't be an issue anymore.

Why is blocking considered a userspace-breaking change?

From the 4 random man page.

"A read from the /dev/urandom device will not block waiting for more entropy."

Because if a certain application expected that /dev/urandom never blocks and it suddenly starts blocking, the application might start behaving not as expected (performance degradation, race conditions, resource starvation, etc).

The proposed change is certainly not make urandom sporadically block the way /dev/random does. It's to make urandom block at boot if the RNG hasn't been seeded at all.

I've been meaning to ask, what's the correct way to ensure urandom has been seeded before you use it?

In fact, there seem to be some strange ideas about urandom floating around on the internet. For example, from http://stackoverflow.com/questions/3690273/did-i-understand-...

The entropy pool and blocking read of /dev/random is used as a safe-guard to ensure the impossibility of predicting the random number; if, for example, an attacker exhausted the entropy pool of a system, it is probable, though highly unlikely with today's technology, that he can predict the output of /dev/urandom which hasn't been reseeded for a long time (though doing that would also require the attacker to exhaust the system's ability to collect more entropies, which is also astronomically improbably).

This implies that urandom needs to be "reseeded" periodically in order to maintain its security.

My understanding is that if urandom has been seeded with 256 bits of entropy, then it's impossible for any attacker to ever predict urandom in any circumstance. If you don't know the seed, then predicting urandom is as impossible as decrypting AES-256 ciphertext that was encrypted with a random 256-bit key. Which is to say, computationally infeasible.

Is that correct? If so, what sort of C code or startup shell script would you recommend running in order to ensure 256 bits of entropy have been collected by the kernel and used as a seed for urandom?

Your understanding is pretty much correct. To quote DJB [1]:

Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

(1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but

(2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test.