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.
/dev/urandom is a Hash chain seeded from
/dev/random, then you could actually predict the next numbers, if you know 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, you can look at 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.