Difference between /dev/urandom and /dev/Random

Question

I recently read a post on the oracle jdbc driver, talking about making the following configuration on jvm running on Linux:

-Djava.security.egd=file:/dev/../dev/urandom

According to the reference, the generation of random numbers with urandom is faster than the default, Random. What is the difference between urandom and Random?

Answer 1

They are system noise generators, that is, entropy.
These noises are used for random number generation and encryption purposes.
Both are native to Unix and Unix-like systems such as GNU/Linux and others.
The /dev/urandom can be used for everything except for security purposes. For there is no locking system when it does not reach enough entropic numbers and in that case it kicks the bucket and says, Fuck it! Go anyway.
Already the /dev/Random does not have a hot head. He is like a supreme master of martial arts. Has a lot of patience and has a lock that only releases when you get enough entropy (noise) to generate encryption order 4096 bits or more.
In windows the responsible for this is the file ksecdd.sys.
Remember that in the Unix-Like system this file is not something physical, it resides in memory and currently, despite the older kerneis it is only read for security.
Well that’s it!
PS:
It only generates noise, entropy, so that openssl and gnupg and other encryption tools can generate encryption keys. When we are generating a key in GNU/Linux often does not have enough entropy and the /dev/Random activates the lock and here comes that message for us to do something like move the mouse like crazy, typing on keyboard or whistling and sucking cane at the same time to see if it helps generate more noise in the system.
PS2:
Unix-based systems like GNU/Linux, use by default the /dev/Random for security purposes. How most servers and supercomputers in the world value security, stability and a source code that can be analyzed to verify that none exists Spybot line of code whether from community developers or from private or governmental organizations, they definitely use Unix-like systems and therefore use /dev/Random, for it is the standard of the system for security purposes.

Answer 2

_Source

Both the /dev/urandom as to the /dev/random are able to generate pseudo-random bits with the difference that one is always available and the other is not.

If the entropy level (from the "Entropy Pool") is below the /dev/random will cease to function, in thesis. Meanwhile in the same situation /dev/urandom will continue to function normally, even at critical levels of entropy.

---

Entropy:

In short, entropy is a truly random data repository. For example, processor temperature, disk usage, power consumption, internet network usage, keyboard usage, mouse usage...

Imagine that two people turn on the computer and enter a same online game, one person can use a different sensitivity, each player will be at a different point of the map making walk more and less, the video card will render different points of the map and the use of memory will be different, the sound produced by the steps and shots will be different.... At the end of a game the entropy collected using this data is completely different between the two players, if we then encrypted a chunk of this entropy the result would be even more different.

Entropy is basically the bits collected from the activities of that device. There are also hardware/specific devices for this activity, such as PQ4000KS and the Truerngpro which tend to produce truly random bits and which can be used as entropy by the system itself, thus creating more "strong entropy".

There is also the polemic Rdrand used and integrated in Intel processors, but there are several criticisms regarding its use. Ignoring this the Rdrand would be a small generator truly random, thus fueling entropy.

Pseudo-Random ("PRNG"):

First we need summarize what is PRNG, it constitutes two bases:

"Unpredictable" to "who see from outside" (but predictable inside):

The generated bits must be unpredictable for those who observe the result from outside the system, basically imagine generating several number from 0 until 9, it must be impossible to know the next number based on the previous answer. If gave 5, it may not be possible to know that the next is 6, or that if the next is 7 the other will be 2. Moreover if generate 6,3,4,5,1,7,7,8,4,2 should be impossible to find out which "Seed" is being used.

Uniformity:

A pseudo-random should generate results with the same odds, the same odds of 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 should be equal if it generates a number of 0 up to 9. A pseudo-random cannot generate more 9 than 0, for example if it generates 10000 numbers (from 0 up to 9) cannot only once have resulted in 0 and in 5000 times generate 9.

PRNG uses entropy (which is truly random) to generate other bits. The entropy serves to generate a "password", in fact it is generated by CSPRNG, which generates a hash of the entropy bits, thus using the resulting hash as a "key" (technically it is more called Seed) and for this reason algorithms continuously keep "changing password" (technically this is called re-seeding). This is done so you can ensure that it will generate bits more securely (understand "security" as: keeping the above two items, "unpredictable" and "uniform", avoiding that Seed may have been "leaked" or have become predictable in some way).

PS: Making it clear that this is an attempt at summary, emphasizing points that I think are important! But there are other details, such as generating an entropy-based CSPRNG to then use in PRNG that are very important. But to avoid confusion, the CSPRNG is based on cryptography, so there is no "uniformity" and must be truly "unpredictable", following the bases of cryptography...

---

/dev/random VS /dev/urandom:

Similarities:

• Both are pseudo-random.

Difference:

• The random If there’s not enough entropy it will stop working.
• The random uses the "Entropy Pool".
• The random keep entropy level high, even if it cannot "consume".
• The urandom will not re-seed if there is not enough entropy, continuing to work.
• The urandom will work even after the boot of the system, where there is not enough entropy, this can be serious.
• The urandom directly uses the CSPRNG result not using "Entropy Pool".

---

Which to use?

Personally urandom, but first say who also uses the /dev/urandom:

• Boringssl (Openssl by Google) uses /dev/urandom.
• Gnupg uses the /dev/urandom (except for key generation, can be changed manually).
• Openssl seems to use the /dev/urandom, need to verify (based on "On systems without /dev/urandom (or similar) device, it may be necessary to install Additional support software to obtain a Random Seed.").

Now the reasons for difference between the two, which favor the /dev/urandom:

• Is always available, except with the device newly connected on some operating systems, consequently your software will be much more stable.
• Although re-seed is important, a Seed is sufficient to generate many pseudo-random bits.
• In any situation (low or high entropy) what will be used is the result of CSPRNG. CSPRNG is, because it is cryptographically secure, based on having an unpredictable output, this is one of the "rules" of cryptography, even in low entropy. Only in rare cases would this be a problem, if the situation really has literally criticized, because there not even the CSPRNG will not have enough entropy.

For all purposes I advise using the /dev/urandom your software will be much more stable (no unexpected interruptions) and will have pseudo-random results. If you want truly random results none of the two will meet that goal.

---

When not using the urandom?

This is delicate, usually for generations of long-lasting keys tends to believe that the use of the random be better. However, good luck, I will wait to type and move the mouse to copy files to another disk...

The use of random for long-lasting and issued keys with low frequency can possible and recommended, generate one key per year, ok. However, if you are going to generate one (or more) key(s every hour or minute, this may become a problem, as there may not be a way to generate the keys due to random block off.

This worsens if the use of random made by a machine directly. Imagine hypothetically using a crontab (a scheduled task) to generate a new key per minute, using random. There is no way the software hit its head on the keyboard to type something, causing it to run out of key for a long time, if it will always depend on this key was already.

The same occurs with session identifications, such as cookies, that need to be random and not repeated. Imagine being without entropy and there is no way to generate more sessions?! If you use the random this can occur (this is the default behavior of PHP up to PHP 7, in PHP 7.1 onwards uses urandom, for example).

The most serious case of urandom is in the boot system, when with extreme certainty there will not be enough entropy and will certainly generate extremely predictable data (in both aspects, for the system and for those who see from outside). Some linux distributions, I don’t know if all, save a file when shutting down the system (not applicable in case of unexpected shutdown), so when you turn on the device the urandom use the saved file as a Seed. In the case of Freebsd the urandom will be blocked while there is not enough entropy, only in this situation.