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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cpgenrandom.asp):
*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* <http://msdn.microsoft.com/library/en-us/seccrypto/security/cpgenkey.asp> 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
-- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
