Open ghost opened 10 years ago
If /dev/random is used as RNG, the read operation for randomness is blocking until more entropy is available. That might cause some programs getting "stuck" during the first boot.
Please note I'm not a cryptographer.
Of course. Dropbear keys and hostapd are perfect examples. However I don't know of an example where these examples would affect other programs during init. First boot times only happen once. It would not surprise me if the time to created the jffs/yaffs filesystem is greater than making keypairs. Its not like we are starting a program which depends on dropbear host keys.
As far as I know, when there is not enough entrophy (every boot) and a WiFi station attempts to assoc and shake hands we can see hostapd back off due to the lack of entropy... The client does eventually connect because this creates entrophy if I recall.
None the less, I would like to know if procd -> cjdns -> genconf blocking other programs during init..
Of course. Dropbear keys and hostapd are perfect examples. However I don't know of an example where these examples would affect other programs during init. First boot times only happen once. It would not surprise me if the time to created the jffs/yaffs filesystem is greater than making keypairs. Its not like we are starting a program which depends on dropbear host keys.
I didn't mean that dropbear in particular might be problematic, but the fact that the whole boot procedure itself seems very predictable to me.
I guess if essential programs like dropbear and hostapd generate keys on boot, we can do it too. It would just be good to know the implications, if there are any.
None the less, I would like to know if procd -> cjdns -> genconf blocking other programs during init..
It isn't, as far as I know.
I swear Android was auto-correcting my use of entropy today.. yeah right Found some functions from tinysrp (from EAD) we could consider..
package/network/services/ead/src/tinysrp/t_misc.c
Is it worth running some genconfs with watch -n1 /proc/sys/kernel/random/entropy_avail
Welcome to the Entropics: Boot-Time Entropy in Embedded Devices http://cseweb.ucsd.edu/~hovav/dist/earlyentropy.pdf
http://www.issihosts.com/haveged/
The haveged project is an attempt to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm. Haveged was created to remedy low-entropy conditions in the Linux random device that can occur under some workloads, especially on headless servers.
cjdns crashey has an getentropy(2) style randomness source now, which is enabled on openbsd and linux >= 3.17. Other sources are still enabled.
We generate the config on first boot, and it will happen after a pretty much deterministic set of prior actions, i.e. other stuff like dropbear keys getting set up as well. I'm wondering whether that should ring alarm bells regarding entropy and key material. Anybody?