Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question
2  
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: 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
1  
@AmanGupta the kernel uses such sources already by default, also a bit of history 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

2 Answers 2

up vote 0 down vote accepted

(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.

share|improve this answer

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.

share|improve this answer
    
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.