On Thursday 28 October 2004 12:46, Shachar Shemesh wrote:
Alexandre Julliard wrote:
Juan Lang juan_lang@yahoo.com 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