CryptoAPI (no, this has nothing to do with licensing! YAY!)

[Travis Michielsen]

On Wednesday, December 19, 2001 10:12 pm, you wrote:
> On 2001.12.19 20:08 Alexandre Julliard wrote:
> > David Elliott <dfe at tgwbd.org> writes:
> > > What bothers me though is that it does not get Intenret Explorer to
> > > load up the RSA CSP.  The LoadLibrary fails because the DllMain
> > > function in the CSP returns FALSE.  I speculate this has something to
> > > do with the fact that a real CSP needs to have its image verified
> > > before it will load.  Or maybe it is something different entirely.
> >
> > Is this rsabase.dll?  If so this is because of a problem with
> > LOAD_LIBRARY_AS_DATAFILE; I have a patch for this somewhere.
> >
> > --
> > Alexandre Julliard
> > julliard at winehq.com
>
> Actually, rsaenh.dll.  I am running IE 5.5 and accessing
> https://internetbanking.suntrust.com/.  Not that this site doesn't work
> with Galeon anyway, but it seemed like a fairly simple way to test the
> crypto functionality.
>
> Running wine --debugmsg +crypt IEXPLORE.EXE I get:
>
> [...]
> trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null),
> szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1,
> dwFlags=f0000000)
> trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced
> Cryptographic Provider v1.0
> trace:crypt:CryptAcquireContextA DLL is rsaenh.dll
> trace:crypt:CryptAcquireContextA Signature is 136 bytes long
> trace:crypt:CryptAcquireContextA Type is 1
> trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll
> trace:crypt:CRYPTOAPI_LoadCSP pCspInfo->ImagePath=rsaenh.dll
> err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114
> err:crypt:CryptAcquireContextA Could not load CSP
> trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null),
> szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1,
> dwFlags=f0000000)
> trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced
> Cryptographic Provider v1.0
> trace:crypt:CryptAcquireContextA DLL is rsaenh.dll
> trace:crypt:CryptAcquireContextA Signature is 136 bytes long
> trace:crypt:CryptAcquireContextA Type is 1
> trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll
> trace:crypt:CRYPTOAPI_LoadCSP pCspInfo->ImagePath=rsaenh.dll
> err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114
> err:crypt:CryptAcquireContextA Could not load CSP
> [...]
>
> I just tried running with +crypt,+relay and I get a crash before the main
> window comes up (with the non-drawn splash screen above everything) in
> INT21_FindFirstFCB on line 788 which is else pFCB = (FINDFILE_FCB *)fcb;
>
> For some reason I cannot use the enter key in the console and trying to
> paste an enter from another window doesn't work either.  So using the
> debugger does not work, hitting Ctrl-C in the console does work though.
> Is this a problem other people are having?  I would have thought someone
> would have reported it by now if that was the case.
>
> Anyway, if you think the patch you have might help me get RSAENH.DLL
> loaded and a bit further then I could probably have https sites working in
> IE shortly.
>
> In any case I think if I just look over this code a little bit and make
> sure there are no absolutely glaring errors there should be no reason not
> to put it in the tree, even if it can't actually load a real CSP for some
> other reason.
>
> -Dave

Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) and 
was going to submit a full patch for it at the end of the week.  My patch, 
however,  has almost a completely different approach to the problem!  
Attached is my version (not quite complete or clean).

These are the main differences and issues I see between our patches:

1) I can successfully acquire/release a context (tested with MSDN sample 
code).  I have not experienced any problems with <loading> a CSP.
2) Currently the ms CSPs can perform but all launch pstores.exe - the 
protected stores service.  This is fine except that it eventually crashes 
with an unhandled exception c0000005 and then becomes unwilling to start 
again.
3) Dependancy functions of pstores and M$ providers not implemented:
(advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, 
mpr:WNetGetCachedPassword, etc.)
4) I do not create any list of providers.  This should not be required as the 
registry is supposed to contain the list of available providers.  Once a 
handle is acquired then we can gain access to the provider by this handle.  
Note: Key and hash objects need to link to the provider handle, when they are 
created.
5) I have not yet considered thread or process safing/locking. Nor have I 
done any reference counting.
6) Seting and getting Key/Hash/Prov Params doesn't consider flags not used by 
the CSP and have meaning in advapi32.dll.
7) I currently do not allow a CSP to drop any of the stardard functions.  
This only affects a few functions, however, as MSDN states these functions 
are *required* for the CSP to have.  If they are not implemented they must  
set the last error as ERROR_CALL_NOT_IMPLEMENTED.
8) You seem to make not use 

Anyway I think the correct thing to do right now is to co-ordinate our work 
to make a single patch and implementation.

I am currently testing this code against windows 98.

 - Travis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crypt.h
Type: text/x-c
Size: 3638 bytes
Desc: Wine Internal Cryptography Header
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20011220/3715d91c/crypt.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crypt.diff
Type: text/x-diff
Size: 46734 bytes
Desc: Crypt differences
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20011220/3715d91c/crypt-0001.bin