* 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 NextGen$ -------------- 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/1e959f98/attachment.pgp>
