CryptoAPI

[Vladimir Vukicevic]

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