Shachar Shemesh wine-devel at
Thu Oct 28 05:46:29 CDT 2004

Alexandre Julliard wrote:

>Juan Lang <juan_lang at> 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 

> *CPGenRandom* is one of the more difficult functions to implement 
> correctly, and it must be done correctly to maintain the security of a 
> CSP. *CPGenRandom* is used internally by the *CPGenKey* 
> <> 
> function, as well by applications when generating data items used in 
> cryptographic protocols such as challenge strings. A CSP is not 
> producing message security if values of the cryptographic keys or 
> challenge strings produced by a CSP are predictable.

The way I read it, the rest of the discussion further enhances this 
point. They are basically saying that the seed should be taken from a 
hardware device, if one is available. If one is not available, they 
mumble that there are some alternatives, but make it clear that they are 
not wholly satisfied with the quality of randomness achieved.

The way I read this, if we get our data from /dev/random we are at full 
liberty to disregard the input seed, as this is a hardware device seeding.


Shachar Shemesh
Lingnu Open Source Consulting ltd.

More information about the wine-devel mailing list