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

[Mike Spross]

Thanks for the tip. I had been trying to figure out which line(s) to comment out to workaround the issue without much success. I saw that Søren Dreijer had the same problem – seems like a bug in the linker when compiling in managed mode. Yet another aside: Previously I had not been including dll.h as a workaround to this linker issue. I simply linked to cryptopp.lib and included aes.h and modes.h and that produced an apparently working version of the managed wrapper DLL – ran great on my machine, but when run on other machines it threw System.NullReferenceExceptions (segfaults). I was able to trace one of the NullReferenceExceptions to BlockCipherFinal’s destructor, specifically the following line in secblock.h (should be around line 93):   delete [] (T *)p;   The above is part of AllocatorWithCleanup::deallocate; it fails when dealing with an AllocatorWithCleanup<unsigned int> allocator. I’ve encountered NullReferenceExceptions/segfaults at other points as well, one in the function CryptoPP::Rijndael::Base::UncheckedSetKey(enum CryptoPP::CipherDir,unsigned char const *,unsigned int), but I haven’t been able to pin down the line number.   I’m wondering if you could tell me straight off if this could be due to the fact that dll.h/dll.cpp defines its own new and delete operators and that by excluding dll.h I may have excluded necessary Crypto++ DLL-specific memory management functionality. The exception is hard to reproduce, so I want to be sure that not including dll.h was the root cause of the problem, if it’s possible to diagnose from what little information I’ve been able to provide here. Should I also perhaps export a GetNewAndDeleteForCryptoPP from my wrapper DLL? I’m thinking that shouldn’t be necessary because the DLL initialization is determinate (i.e. first the wrapper is loaded and then cryptopp.dll is loaded dynamically), but maybe I’m missing something...       From: Wei Dai [mailto:[EMAIL PROTECTED] Sent: Thursday, September 14, 2006 1:41 PM To: cryptopp-list@eskimo.com Subject: Re: .NET compatible version of Crypto++ (Was: VS.NET 2003 Compile Problem)   You're only trying to expose AES, but it looks like the linker is looking for DES, which is not exported from the Crypto++ DLL due to single DES not being FIPS compliant. Why the linker is doing this isn't clear, but I found that you can work around it by commenting out this line in des.h (should be around line 119):     DES::Encryption m_des; ----- Original Message ----- From: Mike Spross To: cryptopp-list@eskimo.com Sent: Friday, September 15, 2006 12:11 AM Subject: RE: .NET compatible version of Crypto++ (Was: VS.NET 2003 Compile Problem)   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?