On Thu, Apr 06, 2006 at 09:18:35PM +0200, Magnus Eriksson wrote: > 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.)
Well yes but if the pseudorandom data is then used to generate your private key, that could be a bad thing. > > >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? People have reported it taking ages to start up - 5 minutes plus - and Ian regards this as a problem. > > (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)" 3: Try to generate some by searching the disk! > > ...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) Ummm... we have a PRNG, the problem is we need a cryptographically secure RNG, not just "take the time of day and hash it repeatedly" ! > > #2 really isn't so bad either, if there's some simple feedback. > > MAgnus -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060406/bc89960b/attachment.pgp>
