Hello, this is an updated version of my rsaenh.dll patch from yesterday with Juan's suggestions implemented: 1.) Changed destruct_... function names to destroy_... . 2.) Removed the multiple-of-four behaviour for handles. 3.) Got rid of the splitting of handle management functions into one table locking function and one function, which actually does the real work. 4.) MD4, MD5 and SHA hashes as well as random number generation will work now even if rsaenh was compiled with libssl-dev headers available, but no libcrypto.so at run-time. 5.) Compilation fixes for the case that OpenSSL was configured to support only a subset of the functions imported by rsaenh.dll. 6.) Uses /dev/urandom instead of OpenSSL's RAND_bytes function. (Do we have to check for the availability of /dev/urandom in the configure script?) If you want to try the patch note the following: - After you have applied the patch you have to run autoheader and autoconf. Then cd dlls ; make_dlls ; cd .. ; configure. - After you have compiled and installed wine, you have to unregister rsabase and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll is meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll only). Greetings, Michael
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). Since this replaces rsabase.dll, you could add a patch to wine.inf that registers this rather than that. Otherwise forward away to wine-patches and see what happens :) --Juan --- Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote:
Hello,
this is an updated version of my rsaenh.dll patch from yesterday with Juan's suggestions implemented:
1.) Changed destruct_... function names to destroy_... . 2.) Removed the multiple-of-four behaviour for handles. 3.) Got rid of the splitting of handle management functions into one table locking function and one function, which actually does the real work. 4.) MD4, MD5 and SHA hashes as well as random number generation will work now even if rsaenh was compiled with libssl-dev headers available, but no libcrypto.so at run-time. 5.) Compilation fixes for the case that OpenSSL was configured to support only a subset of the functions imported by rsaenh.dll. 6.) Uses /dev/urandom instead of OpenSSL's RAND_bytes function. (Do we have to check for the availability of /dev/urandom in the configure script?)
If you want to try the patch note the following: - After you have applied the patch you have to run autoheader and autoconf. Then cd dlls ; make_dlls ; cd .. ; configure. - After you have compiled and installed wine, you have to unregister rsabase and register rsaenh (regsvr32 /U rsabase ; regsvr32 rsaenh). rsaenh.dll is meant to replace rsabase.dll sometime (Windows XP also has rsaenh.dll only).
Greetings, Michael
_______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Juan Lang <juan_lang(a)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. -- Alexandre Julliard julliard(a)winehq.org
--- Alexandre Julliard <julliard(a)winehq.org> wrote:
That doesn't mean we want to block, especially for things like CPGenRandom that don't require the highest quality randomness.
Wait, why don't we require that much randomness? That doesn't make sense to me; we don't know what the expectations of the caller are. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Juan Lang <juan_lang(a)yahoo.com> writes:
--- Alexandre Julliard <julliard(a)winehq.org> wrote:
That doesn't mean we want to block, especially for things like CPGenRandom that don't require the highest quality randomness.
Wait, why don't we require that much randomness? That doesn't make sense to me; we don't know what the expectations of the caller are.
That's why /dev/urandom is a better choice. The randomness is good enough for the vast majority of uses, and it doesn't block the process for no good reason. /dev/random should be used only when we specifically know that anything less than highest randomness is unacceptable. -- Alexandre Julliard julliard(a)winehq.org
--- Alexandre Julliard <julliard(a)winehq.org> wrote:
That's why /dev/urandom is a better choice. The randomness is good enough for the vast majority of uses, and it doesn't block the process for no good reason. /dev/random should be used only when we specifically know that anything less than highest randomness is unacceptable.
I would complain further because there's no obvious way for an application to request "highest randomness", but I see that the pbBuffer argument to CryptGenRandom and CPGenRandom is in in/out parameter and is supposed to be used as a seed. I don't have a good suggestion on how to mix it in, though. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Alexandre Julliard wrote:
Juan Lang <juan_lang(a)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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/s...):
*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/
On Thursday 28 October 2004 12:46, Shachar Shemesh wrote:
Alexandre Julliard wrote:
Juan Lang <juan_lang(a)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
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
*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.
This is *exactly* what /dev/urandom does. -- Alexandre Julliard julliard(a)winehq.org
participants (4)
-
Alexandre Julliard -
Juan Lang -
Michael Jung -
Shachar Shemesh