RE: .NET compatible version of Crypto++ (Was: VS.NET 2003 Compile Problem)

[Mike Spross]

Wei,   I’ll admit I haven’t even looked at the Crypto library in .NET, although I’ve known it is there. I’m supplementing another project by adding FIPS compliant encryption/decryption, but it had already been decided that we would use Crypto++ for the purpose. However, since it needed to callable from a .NET application, I started working on a simple managed C++ wrapper DLL around the Crypto++ DLL -- for now I’m only exposing AES encryption in FIPS compliant mode. The overriding reason for using Crypto++ is FIPS compliance – I will take a look at the .NET Crypto library to see if we can’t use it after all. In any event, I’m wondering if you can shed some light on the link error I mentioned in my original post. From within a managed C++ DLL, I include dll.h but receive the following error during link time:   ManagedCryptoPP error LNK2001: unresolved external symbol "public: virtual void __thiscall CryptoPP::DES::Base::ProcessAndXorBlock(unsigned char const *,unsigned char const *,unsigned char *)const " ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED])   Oddly enough, I can compile and run dlltest.exe just fine – I’m using the same cryptopp.dll and cryptopp.lib files in both instances and in both cases CRYPTOPP_DLL_ONLY is defined. The only difference is that the managed C++ DLL uses an extra compiler switch (/clr) to make it managed, but I don’t see that can screw up the link phase. Any thoughts would be appreciated.   From: Wei Dai [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 1:50 AM To: cryptopp-list@eskimo.com Subject: .NET compatible version of Crypto++ (Was: VS.NET 2003 Compile Problem)   See my other reply about DES. As for a .NET compatible, FIPS-compliant version of Crypto++, it certainly won't happen unless someone volunteers to pay for the FIPS validation testing. (Groove/Microsoft has been sponsoring the previous and current FIPS tests in order to use it in their own product.) But even then I'm not sure it's technically possible. I looked into making Crypto++ .NET compatible a while ago and but ran into various difficulties which I no longer recall.   Also, why use Crypto++ instead of the crypto built into NET?   ----- Original Message ----- From: Mike Spross To: cryptopp-list@eskimo.com Sent: Wednesday, September 13, 2006 4:28 AM Subject: VS.NET 2003 Compile Problem   Hi all,   I’ve written a managed C++ wrapper DLL around the Crypto++ 5.2.3 DLL in order to expose some of the FIPS compliant encryption/decryption classes to .NET applications. I’m compiling the wrapper with VS.NET 2003 in Debug mode. Since I want to use Crypto++ in FIPS compliance mode, I included dll.h, but the linker fails with the message:   ManagedCryptoPP error LNK2001: unresolved external symbol "public: virtual void __thiscall CryptoPP::DES::Base::ProcessAndXorBlock(unsigned char const *,unsigned char const *,unsigned char *)const " ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED])   My main header file brings in dll.h as well as a few other things:   #include "stdafx.h" #include "cryptopp/dll.h"   //for __crt_dll_initialize and __crt_dll_terminate #include <windows.h> #include "_vcclrit.h"   USING_NAMESPACE(CryptoPP) USING_NAMESPACE(std)   I don’t bring anything else in. >From what I can tell, the problem only occurs when the /clr compiler switch is present. The switch is required to in order create a managed wrapper DLL, I cannot remove it. Also, I considered removing precompiled headers in case that might make a difference, but I can’t remove precompiled headers when the /clr switch is present. Is there a possible workaround for this issue and will their ever be a .NET compatible, FIPS-compliant version of Crypto++ available, or are we stuck writing wrappers?