
Major upgrade to FreeBSD’s /dev/random - lelf
https://svnweb.freebsd.org/base?view=revision&revision=273872
======
tptacek
Linux should adapt this work.

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

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

~~~
glhaynes
Why is blocking considered a userspace-breaking change?

~~~
sfilipov
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).

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

~~~
sillysaurus3
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-...](http://stackoverflow.com/questions/3690273/did-i-understand-
dev-urandom)

 _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?

~~~
ckuehl
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._

See also his recent blog post [2].

[1] [http://www.mail-
archive.com/cryptography@randombit.net/msg04...](http://www.mail-
archive.com/cryptography@randombit.net/msg04763.html)

[2]
[http://blog.cr.yp.to/20140205-entropy.html](http://blog.cr.yp.to/20140205-entropy.html)

------
Tomte
Fortuna as option, and slated for being made the default later.

That's great.

------
Animats
How well does this work inside virtual machines? Some virtual environments are
so repeatable they can start random number generators too consistently.

(Academic ref: [http://www.ieee-security.org/TC/SP2014/papers/Not-So-
RandomN...](http://www.ieee-security.org/TC/SP2014/papers/Not-So-
RandomNumbersinVirtualizedLinuxandtheWhirlwindRNG.pdf))

------
ultramancool
Very nice. It's quite interesting how much better the /dev/random
implementations seem to be on FreeBSD and OpenBSD than on Linux. On Linux you
have to choose between long-term blocking on information theory and completely
unblocking sources which can produce insecure output. Wonder if they'll ever
fix this.

~~~
tptacek
urandom _does not produce insecure output_ for userland applications once the
system is booted up. A very annoying quirk in Linux random(4) means that
distributions need to be careful about services at boot, but Linux
applications should virtually always use urandom.

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

The system call interface Linux is pursuing is better than random(4) on any
platform; random generation should be a system call and not a device.

~~~
justincormack
NetBSD has a sysctl to give random data, which cannot fail, which is what
arc4random uses. OpenBSD has their getrandom syscall now (in 5.6). I dont know
of a FreeBSD syscall.

~~~
tedunangst
FreeBSD has the sysctl too. (oh, and openbsd syscall is called getentropy.)

~~~
justincormack
Yeah I knew it didnt have the same name but I forgot what... thanks for the
correction.

