differences between random and urandom
RandomPrngRandom Problem Overview
I'm trying to find out the differences between /dev/random
and /dev/urandom
files
- What are the differences between
/dev/random
and/dev/urandom
? - When should I use them?
- when should I not use them?
Random Solutions
Solution 1 - Random
Using /dev/random
may require waiting for the result as it uses so-called entropy pool, where random data may not be available at the moment.
/dev/urandom
returns as many bytes as user requested and thus it is less random than /dev/random
.
As can be read from the man page:
random
> When read, the /dev/random
device will only return random bytes within
> the estimated number of bits of noise in the entropy pool. /dev/random
> should be suitable for uses that need very high quality randomness
> such as one-time pad or key generation. When the entropy pool is
> empty, reads from /dev/random
will block until additional
> environmental noise is gathered.
urandom
> A read from the /dev/urandom
device will not block waiting for more
> entropy. As a result, if there is not sufficient entropy in the
> entropy pool, the returned values are theoretically vulnerable to a
> cryptographic attack on the algorithms used by the driver. Knowledge
> of how to do this is not available in the current unclassified
> literature, but it is theoretically possible that such an attack may
> exist. If this is a concern in your application, use /dev/random
> instead.
For cryptographic purposes you should really use /dev/random
because of nature of data it returns. Possible waiting should be considered as acceptable tradeoff for the sake of security, IMO.
When you need random data fast, you should use /dev/urandom
of course.
Solution 2 - Random
Always use /dev/urandom.
/dev/urandom and /dev/random use the same random number generator. They both are seeded by the same entropy pool. They both will give an equally random number of an arbitrary size. They both can give an infinite amount of random numbers with only a 256 bit seed. As long as the initial seed has 256 bits of entropy, you can have an infinite supply of arbitrarily long random numbers. You gain nothing from using /dev/random. The fact that there's two devices is a flaw in the Linux API.
If you are concerned about entropy, using /dev/random is not going to fix that. But it will slow down your application while not generating numbers anymore random than /dev/urandom. And if you aren't concerned about entropy, why are you using /dev/random at all?
Here's a much better/indepth explanation on why you should always use /dev/urandom: http://www.2uo.de/myths-about-urandom/
The kernel developers are discussing removing /dev/random: https://lwn.net/SubscriberLink/808575/9fd4fea3d86086f0/
Solution 3 - Random
> What are the differences between /dev/random
and /dev/urandom
?
/dev/random
and /dev/urandom
are interfaces to the kernel's random number generator:
- Reading returns a stream of random bytes strong enough for use in cryptography
- Writing to them will provide the kernel data to update the entropy pool
When it comes to the differences, it depends on the operation system:
- On Linux, reading from
/dev/random
may block, which limits its use in practice considerably - On FreeBSD, there is none.
/dev/urandom
is just a symbolic link to/dev/random
.
> When should I use them? > When should I not use them?
It is very difficult to find a use case where you should use /dev/random
over /dev/urandom
.
Danger of blocking:
- This is a real problem that you will have to face when you decide to use
/dev/random
. For single usages likessh-keygen
it should be OK to wait for some seconds, but for most other situations it will be not an option. - If you use
/dev/random
, you should open it in nonblocking mode and provide some sort of user notification if the desired entropy is not immediately available.
Security:
- On FreeBSD, there is no difference anyway, but also in Linux
/dev/urandom
is considered secure for almost all practical cases (e.g, Is a rand from /dev/urandom secure for a login key? and Myths about /dev/urandom). - The situations where it could make a difference are edge cases like a fresh Linux installation. To cite from the Linux man page:
> The /dev/random
interface is considered a legacy interface, and /dev/urandom
is preferred and sufficient in
all use cases, with the exception of applications which require randomness during early boot time; for
these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.
> If a seed file is saved across reboots as recommended below (all major Linux distributions have done this
since 2000 at least), the output is cryptographically secure against attackers without local root access as
soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys.
Since reads from /dev/random
may block, users will usually want to open it in nonblocking mode (or perform
a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available.
Recommendation
As a general rule, /dev/urandom
should be used for everything except long-lived GPG/SSL/SSH keys.
Solution 4 - Random
Short answer
/dev/urandom
Use Long Answer
They are both fed by the same cryptographically secure pseudorandom number generator (CSPRNG). The fact that /dev/random
waits for entropy (or more specifically, waits for the system's estimation of its entropy to reach an appropriate level) only makes a difference when you are using a information-theoretically secure algorithm, as opposed to a computationally secure algorithm. The former encompasses algorithms that you probably aren't using, such as Shamir's Secret Sharing and the One-time pad. The latter contains algorithms that you actually use and care about, such as AES, RSA, Diffie-Hellman, OpenSSL, GnuTLS, etc.
So it doesn't matter if you use numbers from /dev/random
since they're getting pumped out of a CSPRNG anyway, and it is "theoretically possible" to break the algorithms that you're likely using them with anyway.
Lastly, that "theoretically possible" bit means just that. In this case, that means using all of the computing power in the world, for the amount of time that that the universe has existed to crack the application.
Therefore, there is pretty much no point in using /dev/random
So use /dev/urandom