A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again.
The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves.
At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project.
At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything.
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.
Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff.
As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there?
In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded.
-Dave