Hi,
On Fri, 2001-08-17 at 07:23, Travis Michielsen wrote:
I was going to start implementing the Cypto API (in advapi32.dll) over the next few weeks. As of yet these functions are no more than stubs. However, I am finding increased use of this API as more applications becomed networkable and relying more heavily on internet connections.
I was hoping to implement these functions by using the OpenSSL library (if/when available). This library seems to have similar capabilities.
I had recently thought to start implementing CryptoAPI as well, when someone pointed out your message to me. Have you made any progress? I had planned to implement it as a single monolithic replacement that provided the most common cryptography providers (at least inititally), using libgcrypt. libgcrypt is the back-end library under GnuPG; unfortunately, it is currently under the GPL, so there would be issues with shipping it with wine. I'm not sure what the chances are of getting libgcrypt relicensed under the LGPL -- it's a very nice library. (www.gnupg.org, from CVS)
However, OpenSSL's license is incompatible with the GPL, hence any GPL'd applications that wish to use an OpenSSL-backed CryptoAPI implementation would be unable to do so.
Another question is about design. M$ seems to split the cryptographic software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). Should I do this as well so that, applications can use the native dlls if necessary or should I simply implement it entirely though advapi32.dll which and avoid the need to create several new (and very small) dlls under wine? Because most of the code is already in another library (OpenSSL) creating extra dlls seems abit unnecessary.
Doing this in terms of separate DLL's would most likely be ideal, but in terms of getting something working short-term, it might be good to just do a straight one-dll binding of RSA, DSS, and whatever else OpenSSL supports...
- Vlad