mjung at iss.tu-darmstadt.de
Thu Oct 28 07:05:13 CDT 2004
On Thursday 28 October 2004 12:46, Shachar Shemesh wrote:
> Alexandre Julliard wrote:
> >Juan Lang <juan_lang at 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
> #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.
More information about the wine-devel