On Thu, 6 Apr 2006, Matthew Toseland wrote: >>> 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. So don't do it then. :-) I figured since you mentioned urandom you were saying "try random first, if that doesn't give us as much as we need, then use urandom". >> 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! Yeah. Or fold it into #1. "While we wait I'll start accessing the disk, you can help by typing at random, so please bang away at the keyboard" (and display a progress meter perhaps). >> 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" ! What I meant to say was that that way we get something we know we can trust. Or, how well it can be trusted at least. But then again, I'd rather wait. :-) MAgnus
