Hi,
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.
One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of?
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.
- Travis
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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.
One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of?
OpenSSL appears to have a very liberal license -- the only restriction is that you have to credit the original author. So it's like the original BSD licenses.
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.
Depends on whether any real world apps use those individual DLL's. If not, then you're free to combine them all.
Another question is whether to statically link in OpenSSL, or use dynamic linking (early or late).
I'm very interested in OpenSSL stuff, and have integrated OpenSSL support into a nonblocking server at work. I found the OpenSSL list very helpful.
- Dan
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
Vladimir Vukicevic wrote:
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.
I'm not so sure about this. Question: is it possible to write GPL'd software under Windows that links into, say, USER32.DLL? Answer: yes, because USER32.DLL is considered part of the operating system. It might be that cryptoapi's dll is also considered part of the win32 operating system api, thus allowing even gpl'd apps to dynamically link to it without violating the gpl.
- Dan
On Mon, 2001-09-03 at 15:36, Dan Kegel wrote:
Vladimir Vukicevic wrote:
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.
I'm not so sure about this. Question: is it possible to write GPL'd software under Windows that links into, say, USER32.DLL? Answer: yes, because USER32.DLL is considered part of the operating system. It might be that cryptoapi's dll is also considered part of the win32 operating system api, thus allowing even gpl'd apps to dynamically link to it without violating the gpl.
Sure, but I think it's a fine line to walk.. The Microsoft-provided ADVAPI32.DLL is considered part of the OS, but the API itself is not. If you were to create a replacement ADVAPI32.DLL for use under Windows, I don't think it would be legal for GPL apps to link with it; but hey, IANAL, as they say. In any case, the line is even blurrier with wine, since wine itself isn't part of the OS -- so someone wanting to port a GPL'd windows app [for the sake of argument let's pretend that some exist ;-)] to Linux using winelib might have issues.
- Vlad
-
Dan Kegel -
Travis Michielsen -
Vladimir Vukicevic