search

SeattleMeshnet / meshbox

The Hyperboria peering device
https://github.com/hyperboria/cjdns
GNU General Public License v3.0
141 stars 25 forks source link

--genconf on first boot: entropy issues? #15

Open ghost opened 10 years ago

ghost commented 10 years ago

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?

kpcyrd commented 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.

wfleurant commented 10 years ago

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..

ghost commented 10 years ago

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.

wfleurant commented 10 years ago

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

ghost commented 9 years ago

Welcome to the Entropics: Boot-Time Entropy in Embedded Devices http://cseweb.ucsd.edu/~hovav/dist/earlyentropy.pdf

ghost commented 9 years ago

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.

kpcyrd commented 8 years ago

cjdns crashey has an getentropy(2) style randomness source now, which is enabled on openbsd and linux >= 3.17. Other sources are still enabled.