Hacker News Reader

Comment by jMyles | Hacker News Reader

A lot of people over the years have gotten the message that "use /dev/urandom and forget about it" is the final, end-all, be-all for secure random number generation.

In fact, this ideology (and that's what it is - an ideology) has been trumpeted right here on HN, in some cases by people who repeatedly seem to comment on topics that they don't fully understand. Security is hard, but there's also a high reputational value on being perceived as an authority on the topic. As a result, there are some nuggets of "wisdom" that require asterisks next to them, including this one.

Even though "just use /dev/urandom" is almost always true, it isn't always true. In fact, the universe of cases where some form of blocking entropy is needed (and again, this is a very tiny set) is growing, not shrinking.

https://security.stackexchange.com/questions/186086/is-alway...

View on HN

How does a blocking CSPRNG mitigate this attack?

Again, it makes no sense to say that a CSPRNG can start "running low" on entropy.

Here's what djb has to say about this:

     Cryptographers are certainly not responsible for this superstitious nonsense. 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.

(Unless you're talking about the early boot seeding problem that /dev/urandom has on linux, which is a very real problem).

For reference, here's the classic source I think you're referring to: https://www.2uo.de/myths-about-urandom

The point is not about "running low on entropy", it's about the possibility of not having enough to begin with. At boot.

Part of the problem is that neither /dev/urandom nor /dev/random on linux do what most people want. /dev/urandom never blocks even right after you've spun up a fresh machine that has not seeded the PRNG, while /dev/random blocks very conservatively, to the point where it is not useful for certain things.

The proper approach for high-volume random numbers is probably to seed a userspace PRNG from /dev/random but that's extra work, particularly in a concurrent program.

I think that the approach taken in Python as of PEP524[0] gets it about right. And it achieves a very similar level of exposure and performance across platforms as well.

0: https://www.python.org/dev/peps/pep-0524/

Please do not seed a userspace RNG from /dev/random. Most major crypto RNG attacks trace back to userspace RNGs. If you can trust /dev/random to provide a seed for your userspace RNG, then by definition you can also from that point on trust urandom as well.

(getrandom(..., 0) is probably the right long-term solution).

> (getrandom(..., 0) is probably the right long-term solution)

Glad to see you've come around.

Huh?

First, man - every time I have replied to you on HN, our discussion has turned into a flame war of one variety or another. I don't have time for that at this moment (nor the inclination for it, ever). Ideally, I'd just like to get along with you. We have many common friends; I'm confident they'll tell you that I'm a pretty relaxed guy and easy to get along with. And I'm pretty careful about refraining from stepping into discussions unless I have a good enough command over the material to avoid making false statements or giving bad advice. So I'm just asking - please just be civil. Let's stop clogging HN with attacks and instead just discuss (and achieve consensus on) best practices. Agreed?

Now: as recently as 5 months ago, when you and I discussed the matter, you replied to a post that expressly suggested `getrandom(..., flags=0)` (what you called the "blocking variant", although it's not that simple) and dismissed it in favor of /dev/urandom (and also strangely referred to security.stackexchange as "the wrong stackoverflow boards"). [0]

This was bad advice. It's good to see that you have come around to the position taken by the Python core team and just about everybody else that using getrandom(..., 0) in a best practice in this situation.

0: https://news.ycombinator.com/item?id=17786496

That's not at all what that thread says, and this is an extremely weird and unwelcome addition to this thread.

it was hilarious though

I assumed from context that he meant "GRND_RANDOM" as the "blocking variant" in that thread, which is different from flags=0.

BTW, I've read that before (don't use userspace RNG). Can you point me to a few problems that arose because of userspace RNG?

Yeah, next time we're drinking.

Now I remember about forking and VM cloning issues.

Also, you live a bit far from me, but see you at Black Hat maybe :D

> Part of the problem is that neither /dev/urandom nor /dev/random on linux do what most people want.

Agreed, but `getrandom(..., 0)` largely does. And thus, Python's `urandom` is also a good fit for very nearly every use case for randomness inside business logic.

> The proper approach for high-volume random numbers is probably to seed a userspace PRNG from /dev/random...

At a high-level, I don't agree. I think that for high-volume random numbers the best solution is nearly always a trustworthy hardware RNG.

I also think that, while it's possible to properly seed a userspace PRNG from /dev/random, it's rarely a good idea because 1) it's (at least relatively) difficult to do without introducing other vulnerabilities, and 2) if you trust /dev/random as a seed, then you have other viable options in every case.

If you have a need to use a userspace PRNG - and more importantly, the wherewithall and self-awareness to do it properly, then you are almost certainly in a position to need to seed it from an oracle other than your system's /dev/random.

it's worth, now everyone is dong that in docker.

Reply on news.ycombinator.com