Skip to content
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

Open
ghost opened this issue Aug 4, 2014 · 7 comments
Open

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

ghost opened this issue Aug 4, 2014 · 7 comments
Labels
Milestone

Comments

@ghost
Copy link

ghost commented Aug 4, 2014

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?

@ghost ghost added the help wanted label Aug 4, 2014
@kpcyrd
Copy link

kpcyrd commented Aug 4, 2014

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
Copy link
Member

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
Copy link
Author

ghost commented Aug 4, 2014

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
Copy link
Member

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 ghost added question and removed help wanted labels Sep 27, 2014
@ghost
Copy link
Author

ghost commented Sep 29, 2014

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

@ghost
Copy link
Author

ghost commented Dec 23, 2014

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.

@ghost ghost added this to the shipping milestone Jan 10, 2015
@kpcyrd
Copy link

kpcyrd commented Oct 4, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants