For instance, could it be used to generate a one-time pad key?
Also, what are its sources and how could it be used to generate a random number between x and y?

- 39,467
- 16
- 112
- 140

- 7,519
- 8
- 45
- 52
-
5I don't know for sure so I won't put this as an answer, but the Wikipedia article (http://en.wikipedia.org/wiki//dev/random) is pretty clear in that regard: *`/dev/random` should be suitable for uses that need very high quality randomness such as one-time pad or key generation* - whereas `/dev/urandom` is not – Alexander Gessler Apr 12 '11 at 12:41
-
1@Alexander Gessier So I should just take Wikipedia's word for it? – seriousdev Apr 12 '11 at 12:47
-
2You could also use the references at the bottom of the wikipedia article to get: http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html – CodesInChaos Apr 12 '11 at 12:51
-
Wikipedia is just quoting the [man page](http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html). – Keith Apr 12 '11 at 13:01
-
1There is a link on the wikipedia article to a PDF that reports on a study of /dev/random. – Keith Apr 12 '11 at 13:06
-
Note that the comments in the /dev/random man page have been criticized by many (though not all) people who know what they're doing: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers – Jack O'Connor May 13 '15 at 01:28
3 Answers
Strictly speaking, /dev/random
is not really completely random. /dev/random
feeds on hardware sources which are assumed to be unpredictible in some way; then it mixes such data using functions (hash functions, mostly) which are also assumed to be one-way. So the "true randomness" of /dev/random
is thus relative to the inherent security of the mixing functions, security which is no more guaranteed than that of any other cryptographic primitive, in particular the PRNG hidden in /dev/urandom
.
The difference between /dev/random
and /dev/urandom
is that the former will try to maintain an estimate (which means "a wild guess") of how much entropy it has gathered, and will refuse to output more bits than that. On the other hand, /dev/urandom
will happily produce megabytes of data from the entropy it has.
The security difference between the two approaches is meaningless unless you assume that "classical" cryptographic algorithms can be broken, and you use one of the very few information-theoretic algorithms (e.g. OTP or Shamir's secret sharing); and, even then, /dev/random
may be considered as more secure than /dev/urandom
only if the mixing functions are still considered to be one-way, which is not compatible with the idea that a classical cryptographic algorithm can be broken. So, in practice and even in theory, no difference whatsoever. You can use the output of /dev/urandom
for an OTP and it will not be broken because of any structure internal to /dev/urandom
-- actual management of the obtained stream will be the weak point (especially long-time storage). On the other hand, /dev/random
has very real practical issues, namely that it can block at untimely instants. It is really irksome when an automated OS install blocks (for hours !) because SSH server key generation insists on using /dev/random
and needlessly stalls for entropy.
There are many applications which read /dev/random
as a kind of ritual, as if it was "better" than /dev/urandom
, probably on a karmic level. This is plain wrong, especially when the alea is to be used with classical cryptographic algorithms (e.g. to generate a SSH server public key). Do not do that. Instead, use /dev/urandom
and you will live longer and happier. Even for one-time pad.
(Just for completeness, there is a quirk with /dev/urandom
as implemented on Linux: it will never block, even if it has not gathered any entropy at all since previous boot. Distributions avoid this problem by creating a "random seed" at installation time, with /dev/random
, and using that seed at each boot to initialize the PRNG used by /dev/urandom
; a new random seed is regenerated immediately, for next boot. This ensures that /dev/urandom
always works over a sufficiently big internal seed. The FreeBSD implementation of /dev/urandom
will block until a given entropy threshold is reached, which is safer.)

- 10,032
- 6
- 34
- 48

- 72,986
- 14
- 147
- 189
-
4@thomas-pornin: Not true. Look at slide 63 of http://www.slideshare.net/astamos/cloud-computing-security for a brief note. Basically, in a VM it's not unlikely for there to be insufficient entropy vs the image you cloned unless measures are taken. – jwilkins May 27 '11 at 18:41
-
@jwilkins would the RNG output of the two VMs be effectively unrelated as soon as they received even a single bit of entropy input that was different? (In the same same sense that if I change any single bit of a file, the hash of that file should be totally unrelated to what it was before?) If so, is the VM problem limited to just the first few moments after boot/clone, before the RNG states diverge? – Jack O'Connor Apr 28 '15 at 23:11
-
2To ask the same question in a different way, suppose I have two CSPRNGs using the same algorithm. Generator A is seeded with (X, 0), where X is 256+ bits of entropy. Generator B is seeded with (X, 1), where X exactly the same as for Generator A. Is there any attack that would let me predict the output of B, given the output of A? – Jack O'Connor Apr 28 '15 at 23:18
The only thing in this universe that can be considered truly is one based on quantum effects. Common example is radioactive decay. For certain atoms you can be sure only about half-life, but you can't be sure which nucleus will break up next.
About /dev/random
- it depends on implementation. In Linux it uses as entropy sources:
The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom.
It means that it is better than algorithmic random generators, but it is not perfect as well. The entropy may not be distributed randomly and can be biased.
This was philosophy. Practice is that on Linux /dev/random
is random enough for vast majority of tasks.
There are implementations of random generators that have more entropy sources, including noise on audio inputs, CPU temperature sensors etc. Anyway they are not true.
There is interesting site where you can get Genuine random numbers, generated by radioactive decay.

- 59,039
- 12
- 119
- 163
-
1well depending on how you define *random*, even that is not truly random. – Pacerier Apr 24 '14 at 10:45
-
2@Pacerier is you define random as toast with peanut butter and jam then yes, it is not truly random. By any other meaningful definition it is. – Andrey Apr 24 '14 at 14:38
-
it is not correct. You don't need quantum effects for "true" randomness e.g., classical turbulence models are not less true than quantum theories (the former are less fundumental but it does not matter: we know that the current (quantum) theories are also not a "theory of everything" (there are limitations)). – jfs Jul 30 '15 at 18:11
-
1@J.F.Sebastian I may be wrong but as I understand it there is a difference between very random and truly random. Turbulence, 3 body problem and all those systems are highly chaotic, but they are not truly random. – Andrey Aug 03 '15 at 11:00
-
@Andrey: my point is that turbulence is not merely "very random", it is "truly random". For example, it has a nice property that no matter how much do you know about the system; you won't be able to predict the specific outcome. You can persuade me otherwise with math and/or measurements. – jfs Aug 03 '15 at 12:27
-
@J.F.Sebastian deterministic (not random) system is the one where outcome totally depends on the initial parameters. Random one is where outcome can be different for exactly same initial parameters. Chaotic system is the one where slightest change in the initial parameters produces extreme variations of outcomes. Those system happen to be very hard to solve analytically. As I understand turbulence is a deterministic system and yet extremely chaotic which practically means that in general case outcome can't really be calculated. – Andrey Aug 03 '15 at 12:38
-
@Andrey: from the math side: read about a finite time blowup for 3D Navier–Stokes equations (the equations are one way to model turbulence) — it is an open problem. The hypothesis that all randomness in turbulence can be explained by chaos phenomenon (deterministic but unpredictable due to variations in initial conditions) is not proven. I'm not aware of non-fringe deterministic (in detail, not statistics) turbulence models. From physics side (what you can measure): turbulence is random. – jfs Aug 03 '15 at 15:37
-
@J.F.Sebastian could you provide any proof that turbulence is truly random (and not just unpredictable)? – Andrey Aug 03 '15 at 20:59
-
-
-
@Andrey: the only proof that matters is measurements. If you can't measure it; it is not physics. – jfs Aug 04 '15 at 11:13
-
-
@Andrey: nonsense. There are tons of statistical physics models that are useful (their predictions are in a good agreement with empirical evidence). All models are wrong, some are useful. Their usefulness does not depend on whether the underlying (more fundamental) models are determenistic or not. This argument is unrelated to "God doesn't play dice", Bell's theorem, etc. – jfs Aug 04 '15 at 12:04
-
@J.F.Sebastian there is very clear definition of what is deterministic and what is nondeterministic (random). The fact that system is unpredictable doesn't automatically makes it nondeterministic (random). You need to prove that outcome of system will be different for **identical** inputs. If you can't prove that you can assume it but for valid assumption you also have to have strong reasons. You basically equate unpredictable with random because unpredictable looks random – Andrey Aug 04 '15 at 12:13
-
@Andrey: you are repeating yourself. I understand what you mean by deterministic, unpredictable, random in this context. It does not affect my argument: *"if you can't measure it; it is not physics"* – jfs Aug 04 '15 at 12:27
-
@J.F.Sebastian I don't get any sense out of this conversation. You have to have strong reasons to consider system nondeterministic. Unless you provide those arguments for turbulence I don't see reasons to believe it is nondeterministic. Your phrase about measurements and physics is so general that I don't get it. You can measure turbulence, 3 body system, nuclear decay, ball rolling on slope, and yet all those systems are very distinct in their nature. – Andrey Aug 04 '15 at 15:08
-
@Andrey: obviously, I'm talking about measuring the difference between a physical phenomenon being "true random" or merely "unpredictable" using your terms. What else are we talking about? – jfs Aug 04 '15 at 17:30
-
@J.F.Sebastian and Andrey I found this old exchange entertaining and interesting. Thanks – Adamantish Feb 22 '17 at 19:32
-
For the record I agree with Andrey. Physics without measurement is physics it's just called theoretical rather than experimental physics. If it were eventually discovered that the unpredictability in turbulence emerges entirely due to quantum effects then, yes that's true randomness. Otherwise, if it arises from complex classical interactions it is not random. And here's the difference between the theorist and empiricist: If turbulence is eternally unsolvably chaotic that would be as good as random for all practical purposes but the theorist would rightly still say "not random". – Adamantish Feb 22 '17 at 19:41
-
@J.F.Sebastian I agree that without a theory of everything we can't categorically rule out a discovery that could predict radioactive decay. But it has satisfied a much much stronger fundamental standard of randomness than turbulence. There are no tools in our models of the universe that could even make progress toward cracking it. – Adamantish Feb 22 '17 at 19:48
/dev/random
will block if there's not enough random data in the entropy pool whereas /dev/urandom
will not. Instead, /dev/urandom
will fall back to a PRNG (kernel docs). From the same docs:
The random number generator [entropy pool] gathers environmental noise from device drivers and other sources into an entropy pool.
So /dev/random
is not algorithmic, like a PRNG, but it may not be "truly random" either. Mouse movements and keystroke timings tend to follow patterns and can be used for exploits but you'll have to weigh the risk against your use case.
To get a random number between x
and y
using /dev/random
, assuming you're happy with a 32-bit integer, you could have a look at the way the Java java.util.Random class does it (nextInt()
), substituting in appropriate code to read from /dev/random
for the nextBytes()
method.

- 7,536
- 4
- 30
- 44