What is the state of randomness quality in LEDE? Is it being seeded from really random data like wireless radio noise apart from standard Linux measures? I can see some settings (like system.@system[0].urandom_seed) and scripts (like /etc/init.d/urandom_seed) but no documentation about what they are doing.
At least for the ath9k based radios there is wireless noise an additional entropy:
https://git.lede-project.org/?p=source.git;a=blob;f=package/kernel/mac80211/patches/543-ath9k_entropy_from_adc.patch;h=6f7370203b3d04b53b382bfb7622c821cd05e4ca;hb=HEAD
Genuine entropy has been always a problem for headless embedded devices, as the devices innitially start from he same date/time and with fixed contents of the flashed firmware.
Before LEDE times you can see the discussion in Openwrt in https://dev.openwrt.org/ticket/9631 . Some early fixes for the negative Linux changes 6-7 years ago were rng-tools and haveged as possible entropy sources. The patch linked above was a major step in 2013 in countering the earlier Linux changes. But I am not sure if that measure helps the devices based on the other wifi drivers at all.
The urandom_seed thing is a recent measure to help the router to start the next time with some entropy (that is not fixed in the firmware flash itself). A few bytes from the current entropy is saved for the next reboot.
If you have a hardware rng available in your device, you can use rng-tools package to inject that entropy to the system.
2 Likes
Thanks a lot for the detailed answer. Just one more question: what is the purpose of urandom_seed setting in /etc/config/system? Should I manually change it to something other than the default '0'?
Looks like that by default the seed is saved just once at the first boot after the flash by default (to avoid flash writes as much as possible). With that config setting you can enable new seed to be saved at each subsequent boot by setting the config item to '/etc/urandom.seed' (or other filename to which want to store the entropy seed).
1 Like
Thanks again, so if I don't enable that setting and leave it the default, LEDE will save the seed one time on first boot then after each boot it will use the same seed? Doesn't look very secure to me, so I think I'll enable it in my router.
Saving a new seed on each boot is disabled by default to avoid too much writes without user consent
I wonder whether writing to the flash a couple of bytes after every boot is that much of an issue to sacrifice security for it.
It must depend on the filesystem used and whether it writes data in the same physical blocks or it is aware of flash drive wear issues.
Thanks again, so if I don't enable that setting and leave it the default, LEDE will save the seed one time on first boot then after each boot it will use the same seed? Doesn't look very secure to me, so I think I'll enable it in my router.
Saving a new seed on each boot is disabled by default to avoid too much writes without user consent
I wonder whether writing to the flash a couple of bytes after every boot is that much of an issue to sacrifice security for it.
It must depend on the filesystem used and whether it writes data in the same physical blocks or it is aware of flash drive wear issues.
Remember that the system will pick up randomness from all other sources as well.
Some people are super paranoid about wearing out the flash, so the default is to
not save a new seed every reboot.
This gets re-argued every year or so, but so far the worry about wearing out the
flash has won.
David Lang
2 Likes
There is also the possibility to use CPU time jitter. In kernel configuration it is possible to select the jitterentropy_rng.
1 Like
Keep in mind that QCA's hwrng isn't really of cryptographically good quality, Re: [PATCH 2/2] ath9k: export HW random number generator. While that doesn't worsen the output of /dev/random, using the hwrng output directly wouldn't be a good idea.
1 Like
As VPN and file/disk encryption rendered useless without high quality random number generator, I notice that jitterentropy_rng is now built-in 18.06's kernel and visible with "cat /proc/crypto".
Therefore, I request to developers here to (waste your valuable spare time then) create the respective daemon package from available GPL source: https://github.com/smuellerDD/jitterentropy-rngd.
Many thanks in advance
There is already also "haveged" package that generates high-quality entropy.
Additionally, I noticed a while ago that one cheap hardware randomness USB key "chaoskey" has its driver directly in the Linux upstream sources
https://altusmetrum.org/ChaosKey/
https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/usb/misc/chaoskey.c?h=v4.14.53
So I bought one and packaged that driver into an Openwrt package last month. The kernel package is now already on Openwrt master sources.
The impact of chaoskey on entropy is great e.g. on mvebu routers:
2 Likes
If I want a very fast (up to 2.8 mbps random output) TRNG device, I will spend USD. 12.- delivered to my door.