Item — HN Reader

This is basically a response to the widespread conception that /dev/random has some mechanism whereby it generates "true" random numbers, while /dev/urandom only uses some lowly PRNG.

The idea that a lot of people get from that is that urandom is not much better than Mersenne twister, while /dev/random is the real thing.

And yes, you're right, the argument is precisely "computational security is good enough".

By the way, /dev/urandom is also self-healing.

Which other advantages of /dev/random might be there, apart from the cold boot case?

3 comments

> The idea that a lot of people get from that is that urandom is not much better than Mersenne twister

> And yes, you're right, the argument is precisely "computational security is good enough".

Point of order. MT is not, and is not meant to be, a cryptographically secure random number generator.

Generally speaking, good RNGs may be divided into two categories. First, there are RNGs designed for simulation. Goals: high periods, strong statistical randomness, and speed. Then there are RNGs designed for crypto. These have one primary goal: that even if you knew how the RNG worked, and had a long stream of previous output, you could not [easily] predict the next output.

MT is in the first category. It is trivially predictable given about 650 past integers, since they collectively defined its internal seed.

Yes, that's why I gave the example of MT. People really believe that /dev/urandom belongs to that class of RNG.

A point of order is limited to issues regarding procedure. It is not meant for factual disputes and or differences of opinion.

Shoudn't your comment have been a point of order? :-)

> By the way, /dev/urandom is also self-healing.

Sure, but only when possible and not all the time. I do realize we are only talking about seconds of vulnerability at a time, though.

> Which other advantages of /dev/random might be there, apart from the cold boot case?

I don't know enough about linux's PRNG to say, but as mentioned in some of the other posts, the point is that both APIs are there because they represent two different sets of guarantees. If you need the guarantees that /dev/random provides, then it's there and there's nothing wrong with using it. There are some additional considerations to be aware of, like the fact that it blocks, but I don't think that makes it something to be avoided.

/dev/random also only "heals" "when possible".

But that "when possible" is approximately 100% of the time that bits can be read from it, correct? Is that not the point of /dev/random?

No! That's not how /dev/random works. You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator; that is the difference between it and urandom.

> You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator.

Yes, I understand. It's the same one that /dev/urandom reads out of, if I am not mistaken.

> /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator

Right, and it blocks if it estimates that there is little or no entropy left. So doesn't that mean that approximately (i.e. subject to the quality of the estimation) 100% of the time there is no entropy left, it will block?

I don't know how to respond to that question, because the predicate includes "no entropy left", which is meaningless.

Maybe I should point out that I am a complete novice with regard to this stuff, and I am just trying to understand where my misunderstanding lies. So, my apologies for using imprecise terminology.

Now, I understand that entropy doesn't "run out" on a PRNG in the sense that it can "run out" with an entropy pool. However my understanding is that the purpose of /dev/random is to behave "like an entropy pool" in that the continual reseeding reduces its vulnerability to RNG attacks. So when I say that that the PRNG has "run out" of entropy, I mean that it is behaving more like a PRNG than an entropy pool due to a lack of reseeding.

Is this a valid concern or not? I have seen mixed answers in this thread.

This is basically a response to the widespread conception

Maybe it's just me, but it seems to me that the programming field is chock full of myths and misinformational tales that people actually make decisions with!