-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--genconf on first boot: entropy issues? #15
Comments
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.. |
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.
It isn't, as far as I know. |
I swear Android was auto-correcting my use of entropy today.. yeah right
Is it worth running some genconfs with |
Welcome to the Entropics: Boot-Time Entropy in Embedded Devices |
http://www.issihosts.com/haveged/
|
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?
The text was updated successfully, but these errors were encountered: