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. -- 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/eee00765/attachment.pgp>
