On Thursday 28 October 2004 12:46, Shachar Shemesh wrote: > Alexandre Julliard wrote: > >Juan Lang <[EMAIL PROTECTED]> writes: > >>Looks good to me, Michael, though I'd suggest using /dev/random rather > >>than /dev/urandom: the blocking behavior of the former shouldn't be a > >>problem for Wine (since this DLL makes no timing guarantees anyway). > > > >That doesn't mean we want to block, especially for things like > >CPGenRandom that don't require the highest quality randomness. I think > >in general /dev/urandom is a much better choice. > > I'm with Juan here. I think urandom is not good enough. > > In general, /dev/random should be used when cryptographic keys are > required. MSDN is fairly clear on this matter
If I use /dev/random in my patch the unit tests take more than three minutes without any user interaction. As to be expected, it runs faster if I move the mouse around wildly to generate entropy => Since the typical user clicks around wildly whenever the UI doesn't respond anymore, we will just do fine ;) I think both alternatives are badly broken. I've taken a look into OpenSSL's RAND_bytes implementation: > #ifdef DEVRANDOM > /* Use a random entropy pool device. Linux, FreeBSD and OpenBSD > * have this. Use /dev/urandom if you can as /dev/random may block > * if it runs out of random entries. */ It seems that even the OpenSSL guys didn't find a good solution. The current rsaenh.dll implementation has more severe security flaws than this (e.g. storing the user's private keys in the registry in plaintext). Thus, for the moment I would opt for staying with /dev/urandom. Cheers, Michael
