Random number generator config

Installing and Using OpenWrt
1

From what I understand, this configuration enables rngd to gather entropy from /dev/hwrng and feed it to /dev/random:

config rngd
	option enabled '1'
	option device '/dev/hwrng'

So what is the meaning of the default configuration? Reading /dev/urandom to feed /dev/random does not make sense to me, as both are software based and may share the same entropy pool.

config rngd
	option enabled '1'
	option device '/dev/urandom'

The User Guide also intructs to disable urngd service if /dev/hwrng is in used. Is it because the hardware device is more than enough?

1 Like
2

I don't recall the default, are you saying it's

config rngd
	option enabled '1'
	option device '/dev/urandom'

?

Probably just makes things work if someone installed it despite not having a hwrng.

Absolutely. A hardware RNG should be more robust than a software-based one. You can run rngtest as well as check the entropy with and without your hwrng.

cat /proc/sys/kernel/random/entropy_avail

3

Yes it is the default. The number of sources from which the kernel can gather entropy data on its own is limited. Without rngd, OpenWrt uses urngd by default to feed the /dev/random device.

Back to rngd service: if the option device '/dev/hwrng' means reading the input device /dev/hwrng to feed the output device /dev/random, then the value /dev/urandom shall mean the same, which does not make sense. Why read use /dev/urandom to feed /dev/random while they share the same entropy pool?

4

To be clear, you're aware that rngd should be used for hardware RNGs, correct?

So, rngd should not be used with the software RNGs.

The difference between /dev/random and /dev/urandom is that the former is a blocking device, which means it stops supplying numbers when it determines that the amount of entropy is insufficient for generating a properly random output. Conversely, /dev/urandom is a non-blocking source, which reuses the kernel's entropy pool and is thus able to provide an unlimited supply of pseudo-random numbers, albeit with less entropy. As such, /dev/urandom should not be used for creating long-term cryptographic keys.

Edit, add reference URL: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-encryption-using_the_random_number_generator

Hence /dev/urandom is used to continually provide entropy (albeit weak).

5

Looks like the default value is simply a foolproof solution.

Now I am wondering if I really need to enable the hardware RNG on a typical router usage with PPPoE and WireGuard? OpenWrt only uses urngd by default, which makes me think that should be enough.

I am planning to use OpenWrt as server in the future (SMB, MariaDB, zstd compression, rsync...). What server applications typically make heavy use of the random number generator?

2 Likes
6

This is set as standard in linux kernel since all hdrng have been compromised by NSA or are simply really worthless in general.

But this has become really complex business when the change was made by Linux so you will never ever see more than a value of 1000 in entropy. It is nowadays simply a continuous pool of 1000random numbers moving through so you can actually never seed the same number two times since the last doesn’t exist after it has been used.

But you also can’t use the random number nowadays before it has finished collecting 1000 random numbers.

But there are a lot to read about this change online, just make sure you read the latest and not 5year old articles.

2 Likes
7

Do you have a reference for this?

8

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc1&id=6e8ec2552c7d13991148e551e3325a624d73fac6

1 Like
9

That is quite a statement to make. Can you provide list of compromised RNG devices? So far I remember only earlier Atheros cards being compromised (ath9k?) but that RNG is disabled by default for many years.

1 Like