PRNG is only pseudo-random and doesn't use any 'real' source of entropy;
It does use "real" source of entropy, or to formulate more properly: It does use events happening outside the machine, such as environmental noises:
The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created.
That's interesting; I suppose though that the quality of randomness (entropy) will vary by the type of device in question. Some may have more 'sensors' or other ways to acquire external noise. It should also be kept in mind that a big challenge of hardware entropy is digitizing an analog entropy source without 'moulding' it in a certain way that introduces a bias, which would detrimentally affect the entropy.
Sure, they're well researched and gradually improved in decades of research, but they remain 'pseudo'-random.
Does this make them more susceptible to a brute-force attack? I'm trying to understand what's the weakness of pseudo-randomness, but I feel like beating a dead horse.
To be honest, I don't think a state-of-the-art PRNG (especially if it does use external sources of entropy as you described) will be
realistically easier to attack (think of stuff like a hundred years instead of 200 and numbers like this, if not higher). Even though it might be off by magnitudes from a true randomness source, today's software randomness is usually
good enough for all practical scenarios.
If
/dev/urandom really incorporates what I'd call
true randomness and doesn't degrade its entropy too much, it means it's trying to get more and more similar (or even become) a TRNG in the long run. This again shows that on paper, a TRNG is always better; it's just that it's not always feasible or practical to implement in off-the-shelf devices. Even an outdated, seed-based PRNG is enough for most (
read: non-cryptographic) use-cases, like generating random bytes for something.
By the way, a quick web search revealed, that apparently,
/dev/random is better for cryptograhpy.
/dev/urandom is best used when:
- You just want a large file with random data for some kind of testing.
- You are using the dd command to wipe data off a disk by replacing it with random data.
- Almost everywhere else where you don’t have a really good reason to use /dev/random instead.
/dev/random is likely to be the better choice when:
- Randomness is critical to the security of cryptography in your application – one-time pads, key generation.
Actually, this seems like pretty sensible advice before generating a seed from
/dev/random or
/dev/urandom:
The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in /proc/sys/kernel/random/ and can be displayed by the command cat /proc/sys/kernel/random/entropy_avail and cat /proc/sys/kernel/random/poolsize respectively.
