From what I have read anything under 1000 could potentially slow down cryptographic applications. Those will block until there is enough entropy available. This could, for example, slow down wlan.
Luckily it is simple to fix by installing and enabling haveged:
well, almost everyone uses /dev/urandom those days, and hostapd should need entropy only for key generation (but having more entropy available ist still a good idea, though)
Don’t mess with entropy sources. Just use /dev/urandom.
HAVEGE (HArdware Volatile Entropy Gathering and Expansion) is a piece of user-space software that claims to extract entropy from CPU nondeterminism. Having read a number of papers about HAVEGE, Peter said he had been unable to work out whether this was a “real thing”. Most of the papers that he has read run along the lines, “we took the output from HAVEGE, and ran some tests on it and all of the tests passed”. The problem with this sort of reasoning is the point that Peter made earlier: there are no tests for randomness, only for non-randomness.
The cryptochip used is ATSHA204A. It has a random number generator, but it is somehow complicated to use it regularly as there is an EEPROM(?) with seed values which could get eventually depleted*. So it’s not used for regular seeding of kernel entropy.
*) Disclaimer: I haven’t read the datasheet yet, this is only out of my memory
looking at the sources, seems the TS-7800 board is the only one where this is usable (it’s even mentioned in the kconfig help text)… hyperflous on omnia
Like I said, low entropy could cause some slowdows, that is why I messed with it in the first place. Also, using /dev/random in combination with /dev/urandom, vice versa or only /dev/urandom is a hotly debated topic. However, since reading and learning more about them, I concur albeit with hesitation. This is a very informative post for the people interested in this.
Also came across this post about jitterentropy_rng.ko. In a nutshell, this is a Linux kernel module that measures the jitter of the high resolution timing available in modern CPUs, and uses this jitter as a source of true randomness.
Googling jitterentropy + openwrt lead me to thesechangesets (2 words, 2 url’s). This made me hopeful that it was already enabled on the Turris Omnia. Checking this with lsmod printed the following:
So the kernel module is loaded but from what I understand it needs a userspace daemon, jitterentropy-rngd, to function. Unfortunately, this appears not to be present on the TO.
Random numbers are generated through a combination of the output of a hardware RNG and an internal seed value stored in the EEPROM or SRAM. The external system may choose to update the internally stored EEPROM seed value prior to the generation of the random number as part of the execution of the nonce or random command, for highest security, Atmel recommends that the EEPROM seed always be updated.
So you don’t need to write to EEPROM every time, writing is recommended though.
I’m wondering why the HW RNG needs a seed anyway. Maybe it is better without seed?
Replying to myself, since I got some rngtest numbers to back me up. This was tested on my laptop (with a Qualcomm Atheros AR9485 Wireless Network Adapter), Ubuntu 16.10, running a custom built Linux kernel (4.9-rc7, from Linus git).
rui@wilykat:~$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests…
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=289.026; avg=763.217; max=847.931)Kibits/s
rngtest: FIPS tests speed: (min=20.035; avg=36.910; max=37.995)Mibits/s
rngtest: Program run time: 26108160 microseconds
rui@wilykat:~$
Aside from passing all FIPS tests, the input channel speed numbers are quite interesting.
Bummer. I was wondering why CONFIG_ATH9K_HWRNG hadn’t been enabled yet, turns out it only got merged on Linux 4.5. Oh, well… Looking forward to a (big) kernel update!
The entropy value is permanently around 700. Sometimes I observe its drop below the limit value of 200. One value declined after a long download on the local network and after its completion it immediately increased. I am now noticing the lows around 130.
After installing the haveged value has grown up, but probably this is not the right solution when Omnia has crypto-chip.
Haveged app works with encrypt chip or works independently with another strategy? Why does will allow encrypt chip so low entropy values below 200?
Is it recommended to activate the activity haveged?
4.11.17
– In this time (without haveged) is betwen 130-218 (updater is bad)
Updater selhal:
[string “backend”]:1325: [string “backend”]:1316: Failed to lock the lock file //var/lock/opkg.lock: Resource temporarily unavailable
Turris Omnia - rtrom01 Turris OS 3.9.6 Kernel 4.4.119-082ea0f4a4e204b99821bedcb349ed54-0
Firmware OpenWrt omnia 15.05 r47055 / LuCI 49c3edd5861fd032fa8379ceda525c27a908a114 branch (git-17.212.24321-49c3edd)
Based on the a.m. system the available entropy is hovering around 160 which is way too low. I was under the impression that for such purpose there is a dedicated chip
Random number generation is very important when it comes to cryptography. And to get really random numbers, one needs a good source of randomness (entropy). It has been shown many times that embedded devices, such as SOHO routers, do not have enough sources of entropy, which can lead to security weaknesses. This is why we added a dedicated chip into Omnia, which can serve as a high quality entropy source.
How then to utilize this dedicted chip for a healthy entroty quantity out of the box? What is the purpose of the dedicated crypto chip if it does not produce a healthy amount of entropy?
To my understanding tools like haveged and rng-tools would be just other (pseudo) entropy sources and not procure entropy from the dedicated crypto chip. Deploying such pseudo source would render the dedicated crypto chip obsolete, would it not?
