Feeding /dev/random with disk reads etc

Question

Is there any way to feed /dev/random with sufficient entropy? The data doesn't have to be truly random, i.e. I can append time of day with pid and add 27 to it, it doesn't matter I just want to make it run faster.

I tried to get the ball rolling with dd if=/dev/zero of=/dev/null . I want to know if there's some way I can use add_keystroke_randomness in /linux/random.h to artificially feed /dev/random so that I don't get those unpredictable blocking calls. i.e. I'm willing to sacrifice some randomness in return for speed.

P.S. - please don't suggest using /dev/urandom

Can you elaborate what's wrong with using urandom? It seems to do exactly what you need. — Marco, Oct 13 '13 at 12:57
Assuming this is the issue: "...When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered..." source: http://en.wikipedia.org/wiki//dev/random. That same source: ..."A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block..." — slm, Oct 13 '13 at 13:04
@Marco I know /dev/urandom solves the problem, I just want to know if I can feed /dev/random with disk reads, keystrokes, mouse movements etc. Just curious — Aman Gupta, Oct 13 '13 at 13:14
@AmanGupta the kernel uses such sources already by default, also a bit of history http://archive.cert.uni-stuttgart.de/bugtraq/2003/08/msg00213.html — frostschutz, Oct 13 '13 at 13:42
@frostschutz - I know that already, I'm trying to figure out a way that I can simulate the keystrokes, because the function that is called is not related to actual keystrokes per say. It's add_keystroke_randomness inside /linux/random.h. So there can be a way to say simulate the entire works of shakesphere as a background process by calling that function in turn adding entropy to /dev/random — Aman Gupta, Oct 13 '13 at 13:49
@AmanGupta in that case, you can just write it directly to /dev/random, no? — frostschutz, Oct 13 '13 at 13:58
@AmanGupta The kernel already does that. But it does it in a way that doesn't allow someone to destroy the entropy/randomness the kernel is gathering. A lot of processes related to security need quality randomness, and destroying it is considered quite bad. I would be shocked if there was a way to feed it directly, since that would allow a compromised process to compromise the random pool. — kurtm, Oct 13 '13 at 14:39

score 3 · Answer 1 · answered Oct 13 '13 at 13:10

There are various solutions for generating entropy. For example haveged (which I'm very happy with myself), timer_entropyd, audio-entropyd, etc. etc. they usually yield enough entropy for most applications that use /dev/random. If you want to go all out, there are also hardware random generators, available as USB sticks. Although they may yield less entropy than you'd think...

Still, /dev/urandom is always a good choice when you need data to be available with no delay.

For huge amounts of data (such as overwriting hard disks), none of the random devices are suitable in terms of speed regardless of entropy available; a PRNG based solution like shred does make a better/quicker job of it.

I wanted to know low level hacks to get this work without using third party tools. Do you know of any? — Aman Gupta, Oct 13 '13 at 13:35

score 1 · Accepted Answer · edited Apr 13 '17 at 12:48

(My answer applies to Linux. The general principles apply to other unix variants, but not the random/urandom distinction.)

This is already happening inside the kernel.

It never hurts to inject additional entropy. If you have a bunch of pseudo-random bytes lying around, simply write them to /dev/random, and they will be mixed into the entropy pool.

Havege is a popular program to gather extra entropy.

dd if=/dev/zero of=/dev/null doesn't cause any hardware I/O, so it doesn't add any entropy. Keystrokes contain a tiny amount of entropy.

Note that if you're reading from /dev/random under Linux, you're doing it wrong. The Linux designers got it wrong: they declared that entropy is something that gets used up quickly, which is not the case. The solution to “/dev/random blocks” is not “inject more entropy” but “use the appropriate device instead”. Whether you want to hear it or not, you should read from /dev/urandom.

score 0 · Answer 3 · edited Oct 11 '16 at 19:18

Depending on kernel version, Linux implements add_disk_randomness(), add_input_randomness(), and add_interrupt_randomness() as entropy sources. These correspond to Disk I/O events, Keyboard and Mouse Events, and Interrupt (IRQ) events. See random.c for exact implementation. These sources conditioned, mixed, and stored internally and used to feed blocking /dev/random and non-blocking /dev/urandom drivers. In this case, non-blocking means that a call to /dev/urandom will always produce output even if the entropy pool contains no entropy. However unlikely, /dev/urandom use can lead to low-entropy seeding and predictable deterministic RNG. This in turn can lead to broken crypto with RSA being especially vulnerable to low-entropy conditions. So you shouldn't use /dev/urandom for cryptography. However, boot time /dev/urandom entropy is persistently problematic on headless systems and would require additional entropy sources to operate correctly.

Easiest solution to insufficient boot entropy is to enable RdRand (or RdSeed) via hw_rand, but that requires trusting Intel (and now AMD) black-box implementation. If you happen to use QorlQ then there is an equivalent SEC functionality.

Alternatively, there are software true(?) random number generators that you can implement. My recommendation is CPU Time Jitter by Stephan Muller as it is a well-documented design and easy to integrate with existing system. Keep in mind, it must be compiled without optimizations for maximum entropy results.

Feeding /dev/random with disk reads etc

3 Answers3