rsaenh

[Michael Jung]

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

[Juan Lang]

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  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

[Alexandre Julliard]

Juan Lang  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.

[Juan Lang]

--- Alexandre Julliard  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

[Alexandre Julliard]

Juan Lang  writes:
> --- Alexandre Julliard  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.

[Juan Lang]

--- Alexandre Julliard  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

[Shachar Shemesh]

Alexandre Julliard wrote:
> Juan Lang  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

[Michael Jung]

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

[Alexandre Julliard]

Shachar Shemesh  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.