Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Unless I am totally confused and it doesn't do that.

I want to know whether or not /dev/urandom will gain increased entropy if I take a hardware RNG and plug its entropy into /dev/random.

So to rephrase, if I were to increase the entropy of /dev/random by X bits/sec (that is, /dev/random after injection lets you sample X bits/sec) will that increased entropy transfer over to urandom?

share|improve this question

migrated from Feb 12 at 6:18

This question came from our site for software developers, mathematicians and others interested in cryptography.

While not very relevant, and… (in particular the graph at might be useful reading. – grawity Feb 12 at 6:24
If you had a true hardware RNG you could just use it directly. – Michael Hampton Feb 13 at 5:27

It isn't really accurate to say that /dev/urandom samples from /dev/random. Instead, the two pools are backed by the same source of entropy. When the pools' entropy count reaches zero, they reseed from the shared input pool. So if you give the kernel input entropy in some way, it can use that for either /dev/random or /dev/urandom, depending on which gets read.

However, /dev/urandom is also rate-limited in how often it can ask for reseeding. By default it can only reseed once every 60 seconds.

None of that really matters in practice, because as long as the pool is initially seeded with at least 128 bits or so of entropy, predicting any output would require not only seeing previous outputs but also breaking the algorithms used, including at least the preimage resistance of SHA-1 (which remains unbroken).

share|improve this answer

It depends on the implementation. But typically, /dev/random and /dev/urandom pull entropy from the same pool, so it will.

Diagram from

share|improve this answer

In Linux any data written to either /dev/random or /dev/urandom are copied to both blocking pool (source of randomness for /dev/random) and nonblocking pool (source of randomness for /dev/urandom).

Just look at random_write function.

But data written to /dev/random are not counted by the internal entropy estimator (after all, some local adversary may try to just redirect /dev/zero or some other highly nonrandom source to /dev/random), so if you have problems with blocking /dev/random, just writing to /dev/random does not help.

In Linux write to /dev/random (or /dev/urandom, no difference), but read always from /dev/urandom (once it is seeded - actually the best way is to use new system call getrandom).

I don't know how it works in other Unices.

share|improve this answer

You must log in to answer this question.