Contents

• 1. Check if your system is generating proper entropy
• 2. Pseudorandom number generator (PRNGs)
• 3. /dev/random vs /dev/urandom verdict

Random things aren't random at all. Sometimes, it might be difficult for your beloved PC to generate a proper entropy for things that needs to be random. We will explore the solution behind this peculiar problem.

Like all things in this universe are random, your PC might annoy you for things like it can't find any random entropy and all. This is an error and it is random, like all things are (should have said something random)!

In this journal entry, we will discuss what should you do when this kind of problem occurs.

1. Check if your system is generating proper entropy

To verify, we always see the entropy is in between of certain threshold values. For a healthy system, our entropy should around 4,096 which is the poolsize for your kernel. You can verify this by:

cat /proc/sys/kernel/random/poolsize

This will output the upper limit of your poolsize, before it is again dumped out and becomes zero. System can be said faulty, if its entropy falls below 250 even after long run. Therefore, a good region is 1024 < entropy < 4096. For the values mentioned above, you can refer to the this entry. Check your system's entropy with the following command:

cat /proc/sys/kernel/random/entropy_avail

If your entropy is not in the region, then there below mentioned is the solution you should try with.

2. Pseudorandom number generator (PRNGs)

Previously, we have already discussed this before in this journal entry where we talked about how /dev/random is slower than /dev/urandom. This is because of less entropy collection done by /dev/random since it only collects from less frequent devices (Keyboard interrupts, Mouse motion, disk accesses) etc. Your system may partake in less generation of entropy due to this reason (in cases for servers and CLI based environments). However, there is considerablity for the solution of external (more faster) random number generation. Now now, you won't be needing any specialized hardware setup (although these things exists) for you to generate some random keys. Your processor manufacturer, already provides a TRNG hardware inside it.

Programs like rng-tools, Yarrow (co-devised by Bruce Schneier), Fortuna (successor of Yarrow, implemented in FreeBSD)

Another good thing I would like to mention is, rng-tools, Haveged, Frandom are not suitable for long-term cryptographic keys as mentioned here in this documentation. The community have clearly explained this in their documentation, I am only making it brief.

TRNGs are known in the industry to not generate numbers that random. See Schneier's article on

3. /dev/random vs /dev/urandom verdict

This RFC4086 have also described it well on how the Linux kernel generates randomness for /dev/random by input data from various devices, along with their techniques.

A proper seed generation is always a must to ensure that random bits generated are always different in long term. This is ensured by the kernel by using cryptographically secure PRNG.

However, to quote from the RFC mentioned, I would like to mention this decade old argument on which one is safe. As mentioned on page 29 of this RFC:

/dev/urandom works like /dev/random; however, it provides data even when the entropy estimate for the random pool drops to zero. This may be adequate for session keys or for other key generation tasks for which blocking to await more random bits is not acceptable. The risk of continuing to take data even when the pool's entropy estimate is small in that past output may be computable from current output, provided that an attacker can reverse SHA-1. Given that SHA-1 is designed to be non-invertible, this is a reasonable risk.

In simpler terms, /dev/urandom can be used to generate short term private keys (i.e. for sessions, token, otp, etc.) but /dev/random should be used in cases of keys that cannot be replaced often, like your (LUKS keyfile, SSH keys, GPG keys, etc.). But then again this is a sincere advice from my side, however should the opinions matters yet again, I would advice to refer to this point then.

If you feel like something else should also have been mentioned in this entry, feel free to email me about.

That's all for today! Thank you for reading this journal. Let's see you again next time.