42

I'm using /dev/urandom to generate random data for my programs. I learned that /dev/random can be empty because, unlike /dev/urandom, it doesn't use SHA when there are not enough bytes generated. /dev/random uses "the kernel entropy pool". Apparently it relies on keyboard timings, mouse movements, and IDE timings.

But how does this really work?
And wouldn't it be possible to "feed" the entropy pool making the /dev/random output predictable?

Peter O.
  • 32,158
  • 14
  • 82
  • 96
Antoninarto
  • 701
  • 1
  • 6
  • 12
  • Imho you should replace one of the tags to mention that this question is specific to linux; anyway, about the 2nd part -- no, only root can do that, normal users can only mix in new data, which is harmless. – loreb Nov 14 '13 at 15:50
  • 1
    How is this question specific to Linux? BSD variants including macOS have `/dev/random` and `/dev/urandom` as well. – mttpgn Aug 23 '19 at 12:50

4 Answers4

36

What you are saying is spot on. Yes, theoretically it is possible to feed entropy into /dev/random, but you'd need to control a lot of the kernel "noise" sources for it to be significant. You can look at the source for random.c, to see where /dev/random picks up noise from. Basically, if you control a significant number of the noises sources, then you can guess what the others are contributing to the entropy pool.

Since /dev/urandom is a Hash chain seeded from /dev/random, then you could actually predict the next numbers, if you knew the seed. If you have enough control over the entropy pool, then from the output of /dev/urandom you might be able to guess this seed, which would enable you to predict all the next numbers from /dev/urandom, but only if you keep /dev/random exhausted, otherwise /dev/urandom will be reseeded.

That being said, I haven't seen anyone actually do it, not even in a controlled environment. Of course this isn't a guarantee, but I wouldn't worry.

So I'd rather use /dev/urandom and guarantee that my program doesn't block while waiting for entropy, instead of using /dev/random and asking the user to do silly things, like moving the mouse or bang on the keyboard.

I think you should read On entropy and randomness from LWN, hopefully it will calm your worries :-).

Should you still be worried, then get yourself a HRNG.

Edit Here is a small note on entropy:

I think the concept of entropy is generally difficult to grasp. There is an article with more information on Wikipedia. But basically, in this case, you can read entropy as randomness.

So how I see it, is that you have a big bag of coloured balls, the higher entropy in this bag the harder it is to predict the next colour drawn from the bag.

In this context, your entropy pool is just a bunch of random bytes, where one cannot be derived from the previous, or any of the others. Which means you have high entropy.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
jbr
  • 6,198
  • 3
  • 30
  • 42
  • 2
    Thank you for this really good answer. As a non native english speaker the word "entropy" is kinda hard to get for me. I'm picturing the entropy pool as a memory array that, when is filled with 8/16 bits, prints the corresponding symbol, am I right? – Antoninarto Nov 15 '13 at 09:33
  • 1
    I added a small note on entropy. Hopefully this makes things a little clearer for you. – jbr Nov 15 '13 at 09:47
5

I appreciate the depth of jbr's answer.

Adding a practical update for anyone currently staring at a ipsec pki command or something similar blocking on empty entropy pool:

I just installed rng-tools in another window and my pki command completed.

apt-get install rng-tools
jorfus
  • 2,804
  • 27
  • 23
2

I am in the midst of reading a paper at factorable and made note of the section where it says:

"For library developers: Default to the most secure configuration. Both OpenSSL and Dropbear default to using /dev/urandom instead of /dev/random, and Dropbear defaults to using a less secure DSA signature randomness technique even though a more secure technique is available as an option."

The authors address the tradeoff of an application hanging while waiting for entropy to build /dev/random to get better security compared to a quick, but less secure, result from /dev/urandom.

Mike
  • 39
  • 5
  • Could it be that there is any kind of mistake in your last sentence because there is twice `/dev/random`. – wake-0 Jul 12 '16 at 20:16
  • Good catch, Kevin. The second occurence should be /dev/urandom. /dev/urandom returns results immediately regardless on the level of entropy present. /dev/random will wait/hang for a suitable level of entropy before providing results. – Mike Jul 14 '16 at 02:08
  • 1
    Since they don't block on running out of entropy, couldn't you theoretically "suck up" the entropy by using it yourself (without root), and leaving much less entropy (or none except pseudo) for cryptographic programs? – Katastic Voyage Jan 16 '18 at 00:49
0

Some additional Info:

IRQF_SAMPLE_RANDOM : This interrupt flag specifies that interrupts generated by a device should contribute to kernel entropy pool

Interrupt are what devices like mouse, keyboard etc (devices) are sending asynchronously.