On 6 Apr 2006, at 11:24, Florent Daigni?re (NextGen$) wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2006-04-06 19:19:45]: > >> 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? >> >> Firstly: If /dev/hwrng exists, we don't need to block on /dev/random. >> This is easily fixed. >> >> Secondly: On Windows, we have to use SecureRandom.generateSeed(). >> This >> calls CAPI, the Windows built-in entropy source. However on linux >> it does >> a blocking read of /dev/random. So we can get blocked even though we >> haven't actually tried to read /dev/random ! Solution: Only use >> SecureRandom.generateSeed() in the constructor on Windows. It might >> possibly have other sources on Linux, so it should still be used >> sometimes, but not blocking... if we don't want to block for real >> entropy. Do we? That is the question: >> >> 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 >> get enough entropy. There have been practical attacks on e.g. >> Netscape >> relating to lack of entropy, however /dev/urandom and Yarrow are far >> more secure... PRO: The user never needs to know anything about this. >> >> 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... >> >> >> #1 is probably Good Enough. > > I would vote 3, at last resort 2
I vote for #1 on the assumption that it is a quick fix, and then aim for #3 as a longer term bug. Ian.
