> Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG
In Linux we already have this with /dev/random, right?
back
3 comments
Yes, modulo "carefully audited", but the problem isn't that it's not possible; the problem is that so few applications rely on it, and that there's folklore encouraging people not to use it.
http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
Are you saying that that article is wrong? I was under the impression that /dev/random and /dev/urandom on Linux were exactly the same thing, but with urandom not being limited by the (very questionable) entropy counter.
I'm pretty sure they are exactly the same on many of the BSDs.
The thing is, /dev/urandom is not even limited by the entropy counter when there is no entropy in the system at all. That was the reason for the RSA factor collisions: The software just used /dev/urandom during boot time when the embedded systems did not have enough entropy available. As a remedy the libreSSL team asked for a Linux syscall with the feature to block if and only if the random pool has not been seeded with at least 128bit of randomness: https://news.ycombinator.com/item?id=8049180
That's a Linux bug with a universally-deployed userland workaround. There's no question that urandom should work on Linux the way it does on FreeBSD, but that's not a reason to avoid urandom in userland software. The death toll from avoidance of urandom is enormous; the death toll from this bug... isn't.
I would say it was both a Linux and a application bug, you could just open an fd on both random and fallback onto urandom or even better supplement random with a prng such as haveged.
"Supplementing" random(4) with a userspace PRNG is exactly the anti-pattern that Bernstein is talking about.
I'm pretty sure they are exactly the same on many of the BSDs.
* OpenBSD: /dev/random + /dev/urandom are the same and use ChaCha20.
* FreeBSD: They are the same (via symlink) and use RC4. Soon will use ChaCha20.
* NetBSD: Unsure. Last I checked, /dev/random was broken/non-functional like on Linux, and /dev/urandom was slow, like on Linux.
* Dragonfly BSD: Somewhat unsure, but ChaCha output can be xor'd with another stream to produce the returned random numbers.
* Bitrig: when it is released, it will use ChaCha20 like OpenBSD.
Related: libbsd currently uses RC4 in its arc4random functions but has publicly stated a future switch to ChaCha20.
I wrote that article, so, no.
if /dev/random decides that it has not not enough entropy sources then reading from it blocks - sometimes it blocks for a minute if the machine has few entropy sources (for example no mouse and no keyboard attached)
That's why most libraries use /dev/random to seed their own RNG, he says that's wrong and that /dev/urandom (which does not block) is scary.
Usually libraries (openssl,JCE) RNG seeds from /dev/random - this is the internal state of the RNGb; internal state is transformed into next iteration by applying SHA-1 and at each turn some initial bits of internal state are returned as random numbers.
of course the library RNG comes from the requirement for a lot of randomness in most protocols, (and for predictable performance, also servers also may need to do a lot of random numbers) of course the article has many points.
Seeding a userspace RNG with /dev/random is exactly the anti-pattern Bernstein is talking about. It's what broke the Android RNG. Don't do that. Just use urandom.
There's a comment about /dev/random and /dev/urandom later at the article.
TLDR - they are broken. He does not even care to explain why it's broken, because everybody knows it.