Linux dev urandom dev random

When to use /dev/random vs /dev/urandom

The longer answer depends on the flavour of Unix that you’re running.

Linux

As @DavidSchwartz pointed out in a comment, using /dev/urandom is preferred in the vast majority of cases. He and others also provided a link to the excellent Myths about /dev/urandom article which I recommend for further reading.

• The manpage is misleading.
• Both are fed by the sameCSPRNG to generate randomness (diagrams 2 and 3)
• /dev/random blocks when it runs out of entropy, so reading from /dev/random can halt process execution.
• The amount of entropy is conservatively estimated, but not counted
• /dev/urandom will never block.
• In rare cases very shortly after boot, the CSPRNG may not have had enough entropy to be properly seeded and /dev/urandom may not produce high-quality randomness.
• Entropy running low is not a problem if the CSPRNG was initially seeded properly.
• The CSPRNG is being constantly re-seeded.
• In Linux 4.8 and onward, /dev/urandom does not deplete the entropy pool (used by /dev/random ) but uses the CSPRNG output from upstream.
• Use /dev/urandom .

Exceptions to the rule

1. Shortly after boot on a low entropy device, if enough entropy has not yet been generated to properly seed /dev/urandom .
2. Generating a one-time pad with information theoretic security

If you’re doing (2) you’ll know it already 🙂

Note: You can check if reading from /dev/random will block, but beware of possible race conditions.

Alternative: use neither!

@otus also pointed out that the getrandom() system will read from /dev/urandom and only block if the initial seed entropy is unavailable.

There are issues with changing /dev/urandom to use getrandom() , but it is conceivable that a new /dev/xrandom device is created based upon getrandom() .

macOS

macOS uses 160-bit Yarrow based on SHA1. There is no difference between /dev/random and /dev/urandom; both behave identically. Apple’s iOS also uses Yarrow.

FreeBSD

/dev/urandom is just a link to /dev/random and only blocks until properly seeded.

This means that after boot, FreeBSD is smart enough to wait until enough seed entropy has been gathered before delivering a never-ending stream of random goodness.

NetBSD

Use /dev/urandom , assuming your system has read at least once from /dev/random to ensure proper initial seeding.

/dev/urandom never blocks.

/dev/random sometimes blocks. Will block early at boot if the system’s state is known to be predictable.

Applications should read from /dev/urandom when they need randomly generated data, e.g. cryptographic keys or seeds for simulations.

Systems should be engineered to judiciously read at least once from /dev/random at boot before running any services that talk to the internet or otherwise require cryptography, in order to avoid generating keys predictably.

BSD: Use /dev/urandom — Except there is no such thing as a /dev/urandom on OpenBSD. OpenBSD has /dev/arandom , but you aren’t supposed to use it, you should use the arc4random(3) function instead. Perhaps advise about random devices and functions should be left to people who actually understand what all that is about?

@SatoKatsura Good catch. Updated to FreeBSD to reflect the quote. How would you propose to determine who those people are?

» /dev/random blocks when it runs out of entropy» — On Linux, it depends how you open the device. If open flags include O_NONBLOCK then it won’t block. If there is no entropy then the call will return immediate and indicate 0 bytes read.

@TomHale The behavior is less surprising IMO. If /dev/random is only (ex:) 60 bytes, dd will give you a 60 byte file. Using head in the same scenario will probably look like it’s hanging forever. Neither is doing what you want, but, at least for me, it’s more obvious that head isn’t doing what was expected.

This is somewhat of a «me too» answer, but it strengthens Tom Hale’s recommendation. It squarely applies to Linux.

According to Theodore Ts’o on the Linux Kernel Crypto mailing list, /dev/random has been deprecated for a decade. From Re: [RFC PATCH v12 3/4] Linux Random Number Generator:

Practically no one uses /dev/random. It’s essentially a deprecated interface; the primary interfaces that have been recommended for well over a decade is /dev/urandom, and now, getrandom(2).

We regularly test /dev/random and it suffers frequent failures. The test performs the three steps: (1) drain /dev/random by asking for 10K bytes in non-blocking mode; (2) request 16 bytes in blocking mode (3) attempt to compress the block to see if its random (poor man’s test). The test takes minutes to complete.

The problem is so bad on Debain systems (i686, x86_64, ARM, and MIPS) we asked GCC Compile Farm to install the rng-tools package for their test machines. From Install rng-tools on gcc67 and gcc68:

I would like to request that rng-tools be installed on gcc67 and gcc68. They are Debian systems, and /dev/random suffers entropy depletion without rng-tools when torture testing libraries which utilize the device.

The BSDs and OS X appear OK. The problem is definitely Linux.

It might also be worth mentioning Linux does not log generator failures. They did not want the entries filling up the system log. To date, most failures are silent and go undetected by most users.

The situation should be changing shortly since the kernel is going to print at least one failure message. From [PATCH] random: silence compiler warnings and fix race on the kernel crypto mailing list:

Specifically, I added depends on DEBUG_KERNEL . This means that these useful warnings will only poke other kernel developers. This is probably exactly what we want. If the various associated developers see a warning coming from their particular subsystem, they’ll be more motivated to fix it. Ordinary users on distribution kernels shouldn’t see the warnings or the spam at all, since typically users aren’t using DEBUG_KERNEL.

I think it is a bad idea to suppress all messages from a security engineering point of view.

Many folks don’t run debug kernels. Most of the users who want or need to know of the issues won’t realize its happening. Consider, the reason we learned of systemd’s problems was due to dmesg’s.

Suppressing all messages for all configurations cast a wider net than necessary. Configurations that could potentially be detected and fixed likely will go unnoticed. If the problem is not brought to light, then it won’t be fixed.

I feel like the kernel is making policy decisions for some organizations. For those who have hardware that is effectively unfixable, then organization has to decide what to do based on their risk adversity. They may decide to live with the risk, or they may decide to refresh the hardware. However, without information on the issue, they may not even realize they have an actionable item.

The compromise eventually reached later in the thread was at least one dmesg per calling module.

Источник

What are /dev/random and /dev/urandom in Linux?

Both /dev/random and /dev/urandom are used for generating random numbers in Linux. Learn more about them.

The short answer to that question is «means of generating random numbers.»

And I’m sure you are aware of that.

But to understand the use of /dev/random and /dev/urandom , first, you’d have to know why generating the random is so important.

Why generating random numbers is crucial?

Computers are machines and work on a set of instructions (that’d why we create programs to make them work).

And that’s why it is not possible to ask the machine to think of any random number.

You may ask, why generating random numbers is so important? the answer is simple.

Security concerns.

Most cryptographic algorithms are based on generating random numbers as those numbers would, later on, be used to create cryptographic keys.

And if the generated numbers are not completely random in nature, it makes the whole cryptographic technique weak.

As those keys can be predicted quite easily. And this is the most crucial reason to generate random numbers.

So how Linux tackles this situation? Simple, it’s the topic of today’s discussion.

Using /dev/random and /dev/random.

The use of /dev/random and /dev/urandom

You guessed it right. They both are used to generate random numbers.

They both are used to provide an interface to the kernel’s random number generator.

The random number generator will gather random input from external sources including device drivers into the entropy pool.

But there is a huge difference between /dev/random and /dev/urandom as they follow different approaches to generate random numbers.

How /dev/random will generate random numbers

The /dev/random will only return the random numbers from the entropy pool and if the entropy pool is empty or it does not indicate enough randomness, the reads to the /dev/random will be blocked.

Making it ideal for generating high-quality randoms.

How /dev/urandom will generate random numbers

The random(unlimited random) will use the entropy pool to return the random numbers but if the entropy pool is empty, it will generate data using SHA, MD5, or any other algorithm.

This means, unlike the /dev/random , it won’t block the reads and will continue to get you the random numbers even if there is not enough randomness.

Which one to choose?

The ‘Random’ and ‘Urandom’ are made for the specific use cases. The Urandom is used when there is a constant need for random numbers and its randomness is not much important.

Whereas the Random is suitable for tasks where security is a prime concern as it will block the reads if the randomness is not up to the mark.

Although the randomness of Urandom is just slightly weaker than the Random , it is still used by many operations but I would recommend you go with Random (if you insist on having strong security).

Bonus: Generate a random password using Urandom

To generate a random password using the Urandom , all you have to do is follow the given command:

Here, the tr command will get you to filter output from /dev/urandom such as it will get your password from A to Z , a to z and 0 to 9 .

The head command will generate a string of 14 characters (using -c14 ).

Wrapping Up

In this guide, I explained the basics of /dev/random and /dev/urandom including the need for randomness.

And if you are curious, I use Urandom it to generate passwords as I find it robust and less likely to have errors that you may encounter using Random .

I hope you will find this guide helpful and if you have any queries, let me know in the comments.

Источник