Comment by sturmeh | Hacker News Reader

Comment by sturmeh | Hacker News Reader

The issue is that if you run the same program twice without selecting a suitably random seed you will make the same 60 million rolls.

If you can somehow control, predict or influence the seed you can predict or influence rolls.

For example if the game uses JUST the system time as a seed, I can shift the system time back to a specific position and run the application again to get the same random number generation.

If you know the algorithm, for example you're playing an open source card game, and you can determine the time (offset) on the server or the other players computer you could cheat by calculating their random variables.

Now it really isn't an issue in games, but it's incredibly important in security. Randomness makes up a huge component of encryption.

That's why you have applications that require you to move the mouse a bit, hopefully randomly and they take in a whole bunch of other entropy fed in by the system.

In Unix-like OS's you have /dev/random and /dev/urandom. /dev/random requires a certain amount of entropy and environmental noise, and it blocks on reads until it's satisfied with the output.

/dev/urandom does not block, but it gives pseudo random output. For the purposes of security, /dev/urandom should NEVER be used. However neither are truly 'random'.

No. Cryptographic applications on Linux should use urandom, not random. Your belief that urandom should "NEVER" be used is due to an urban legend perpetuated by a badly written Linux man page.

Before you listen to anyone "explaining" to you that /dev/random is good for cryptographic secrets and /dev/urandom is good for everything else, consider that Adam Langley owns Golang's crypto code and Golang's crypto/random interface just pulls from /dev/urandom; Daniel Bernstein, Tanja Lange, and Peter Schwabe --- all cryptographers, with a pretty serious Unix pedigree --- wrote Nacl, an extraordinarily well-regarded crypto library, and Nacl's CSPRNG... wait for it... just pulls from /dev/urandom.

But for any other purpose than generating private keys one should NEVER use /dev/random. If you're not sure use /dev/urandom.

I've had to painstakingly explain to certain people why, as an example, erasing a HDD from /dev/urandom is allright. And why their program that simulates some random input should use /dev/urandom.

But no, they babble about true randomness and then complain why they get like paltry few hundred bytes per second.

Even if you have a server running casino games just use /dev/urandom/. It requires a total compromise of the server to get the internal state out of that, and in that case it's easier just to change urandom into /dev/zero.

If you need a lot of entropy, it's good to use a hardware RNG to keep the load down (and it improves quality).

You should be careful when using word like quality in this context. Some might think that by quality you mean any kind of statistical property. E.g dice rolls generated by either of them are somehow statistically different, which they are not.

What does this mean in practice: If I give you 10 10MB files. 5 of them created with urandom and 5 of them created using hardware RNG there is practically no chance that you could differentiate which came from which, barring knowledge of the urandom entropy pool.

But it is true that HW RNG could be useful just to keep CPU load down. By now we know that those are backdoored by NSA, so you should still use /dev/random as a source for private keys. So HW RNG is useful just to keep the load down. Not to avoid any attacks.

This is so important that I'll have to repeat it again: The only difference between urandom and random is that urandom is theoretically suspectible to an attack which could allow prediction of the output values if the attacked knows the internal entropy pool state. The statistical properties of both are the same.

Agreed that some (e.g. RDRAND) are potentially untrustworthy, but others aren't - for example, linux has daemons available that can source entropy from audio or video noise.

A growing number of chipsets have them built in and accessible.

Many new Intel chips do (though off the top of my head I can't tell you how easy to access it is).

The SoC used in rPis units has one that can be read from at over half an Mbit per second via /dev/hwrng (once the relevant module is loaded), so you can either use it directly or (better for portability) keep reading from /dev/urandom and use rngtools to feed the entropy into the kernel's pool as needed.

In both the above cases there is a trust issue as exactly how the RNGs work is not publically documented, but unless you are extremely paranoid (by neccesity or "issues"!) I woudl consider them decent sources of entropy.

That's exactly the wrong advice.

You should always use /dev/urandom on Linux for cryptographic use, unless you know exactly why you need /dev/random. Hint: you don't.

(On FreeBSD it doesn't matter because it's all the same)

I've been meaning to write up a coherent summary of that issue with all kinds of sources forever now, and I should really get around to just doing it, because this comes up every few weeks on HN.

I have no idea why you would use /dev/urandom over /dev/random, or vice versa. If you can write something, I would be very grateful.

The short version is as follows: /dev/random is basically the entropy pool. There isn't much data in there and whatever lands in it must be carefully chosen to prevent entropy going down (Debian accidentally broke that part a few years ago). Since there isn't much data you probably shouldn't take too much of it when you can help it because if it runs out, it blocks until there is enough entropy back in the pool.

/dev/urandom on the other hand is a CSPRNG that is regularly re-seeded from /dev/random. The purpose is to stretch the avilable entropy to more (pseudo-)random numbers. Since it's a CSPRNG the sequence is deterministic but impractical to predict, re-seeding helps in preventing others from observing too much output to reverse-engineer the seed.

So advice is generally to only use /dev/random when you're implementing something like /sev/urandom and for SSL keys and the like you just use /dev/urandom.

No, no, no, no.

/dev/random and /dev/urandom are two interfaces to essentially the same CSPRNG.

On Linux, unlike FreeBSD (where there is no difference between the two), there are two differences between random and urandom:

(1) random will block when a kernel entropy estimator indicates that too many bytes have been drawn from the CSPRNG and not enough entropy bytes have been added to it

(2) urandom and random pull from separate output pools (both of which receive the same entropy input, and both of which are managed the same way).

It is not true that /dev/urandom is a PRNG and /dev/random is not; it is not true that /dev/random is a CSPRNG and /dev/urandom is just a PRNG. They are the same thing, with a extremely silly policy difference separating them.

I stand corrected, then.

Thanks to both of you for responding. I will need to read more to understand in detail, but you have at least given me some pointers.

The Debian accident was related to the openssl PRNG, not the kernel's.

Reply on news.ycombinator.com