rsaenh

[Juan Lang]

Michael wrote:
> There is also a DES implementation in dlls/advapi32/crypt_des.c.
> However, this one is not exported by advapi32.dll. I could copy the
> code over to dlls/rsaenh, but this would mean unnecessary code
> duplication. How are such cases handled in wine typically?

They are typically handled by copying the code.  If linking between the
two requires a private export, then our DLLs can't work with native ones,
and that's something we try to avoid.  If we use a static library, the
number of static libraries can potentially get very large, and the
makefiles unmanageable.  It's really best to accept code duplication,
especially for something like DES that is quite stable. 

> Although it is of no concern at the moment, another problem will arise
> in the future: advapi32 and cryptographic service provider dll's check
> each other against tempering by the use of digital signatures in
> windows

Yes, I know.  The functions in advapi32 for verifying a provider always
return success at the moment, unfortunately.  Maybe with more crypto
support we can tackle this, but not yet.

> (Probably because of US export restrictions on cryptographic software).

I'd be surprised if this were the motivation.  US export restriction is on
key length, not on algorithm, and the signatures don't say anything about
these, just that the files have not been modified and their source can be
verified.  I expect the motivation is more along the lines of, I'm
trusting these DLLs to encrypt my credit card number and whatnot, so how
can I trust the DLLs?

--Juan


		
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo