On Thu, 6 Apr 2006, Matthew Toseland wrote: > At present, sometimes the node will freeze on startup, because > /dev/random isn't returning any data. This is unacceptable. How to deal > with it?
> Do we want to block until we get some real entropy? > Option 1: Don't block on startup for entropy: Start a read of > /dev/random in the background, wait a second or two, and then continue > the start up. Use /dev/urandom if we have to. CON: In theory we won't Eh, why not just read urandom directly? Is urandom directly connected to a pseudorandom-number generator on Linux? (On Net/Free -BSD, at least, it returns "proper" randomness as far as possible, before starting to make things up.) > Option 2: Start Fproxy without a real node identity, and create one when > we have enough entropy to do that. Tell the user to make some entropy. > Option 3: Do some disk access to generate some entropy, if we can't get > some immediately. CON: The user will think we are installing spyware. We > can tell them what we are doing, combined with option 2... Ew... 4: Do nothing. So what if it occasionally takes a long time to start? How much randomness is needed anyway? Is this a real problem, or is Freenet only ever going to be slow if you're actively draining /dev/random? (added for completeness) 5: My preferred solution would be to ask the user (if a certain time has passed and there's not enough). "Freenet needs to have some more entropy (random numbers) before starting. What should we do? 1: Wait a little longer, and see if things ''clear up''. 2: Start anyway. (this could theoretically be insecure)" ...while still blocking on /dev/random. Maybe even give up if waiting doesn't help, and present the user with "give up" / "go ahead". 6: Or even implement a pseudorandomness generator in Freenet. (and use it directly / write the results to /dev/random if reading blocks) #2 really isn't so bad either, if there's some simple feedback. MAgnus
