Immediate effect of writing to /dev/random

Question

For reasons best described as philosophical, I'd like to know the following. Assume I am going to read from /dev/random (or /dev/urandom) at time X. In one scenario I just do that, but in another, with /dev/random in the identical state, I push some number of bytes into /dev/urandom right before time X. Are the outputs the same? Ignore the case where by vast, freak coincidence, the particular bytes I write happen leave the state of /dev/random in the same state they were before.

Another way of asking: does writing to /dev/random immediately change (barring unlikely coincidence) the state of /dev/random, or is there some sort of buffering (either of input or output) that means that /dev/random will be affected by my writes, but only in a potentially distant future?

Note: I'm not using the ioctl to claim extra entropy is available when I write.

I want to stress that this is not an "important" question, and I fully grok that for all I know, that some quantum randomness hardware might change state because someone across the world yawned or didn't yawn, let alone whether I do or don't do a write. This question is strictly about whether the act of writing to /dev/random makes an immediate change of state in the software, or whether /dev/random has buffered what you're going to get next (or buffers what you write to it until it decides to reseed something), and so the effect of writes is delayed.

Since this question is clearly off the wall, let me explain why I'm asking. I run a game where outputs from /dev/random are used to decide game outcomes. During the game, people are talking over mumble and I take a real time copy of that audio stream, hash it, and push it into /dev/random. What I'm trying to decide is if I can claim, accurately but absurdly, "If you hadn't just said that, you wouldn't have rolled that 1", or whether I should only make the weaker claim "what you said is going to come back to haunt your die rolls someday."

Also of interest, whether "affects it now" is likely to be a permanent property of /dev/random or is just a fluke of the current implementation.

Thanks!

Answer 1

(Assuming the documentation in drivers/char/random.c is correct,) anything you write is directly mixed into the entropy pool and the random output is a hash of that pool. So the change should be immediate.

However, reading /dev/random might block (when entropy is empty) and write (using poll) might also block (when entropy is full), and writing to /dev/random may just be very slow in general. So there are some performance considerations with this idea.

If you want random data to depend on your users mumblings, you could skip /dev/random altogether and just roll everything through your own SHA function instead. That would give you complete control over the state as well. So you could give each user their own hash instance so their random numbers are entirely based on their own voices. Not depending on system randomness and also not depending on what other people say. Which might also allow them to cheat if they learn your hash function implementation and send prepared audio patterns. ;-)

But that aside, the whole idea is rather esoteric. Random data is just unpredictable and so are hash results; unless you don't want it to be random, there's not much point to doing all this over just reading /dev/_u_random and never writing anything back to it.