Re: Heal corruption problems

[David Myers]

I've typically passed the encryption key as a stack variable rather than an allocation.  That's what I thought I was seeing in the dlltest program.  Is this not proper?

 

Second, why is GetPowerUpSelfTestStatus failing when I set the memory allocator but not when I don't?  By the way, if I specifically call DoDllPowerUpSelfTest before I call GetPowerUpSelfTestStatus, then GetPowerUpSelfTestStatus  succeeds.

 

Finally, my application is an MFC application using MFC as a statically linked library.  Are there any special considerations to this kind of application?

Thanks again for any help.

 

On 1/12/06, Jeffrey Walton <DIGI...@aacounty.org> wrote:

Hi dmyers,

This is also from the readme.txt. A lot of people miss it...

*** Important Usage Notes ***

1. If a constructor for A takes a pointer to an object B (except
primitive
types such as int and char), then A owns B and will delete B at A's
destruction.  If a constructor for A takes a reference to an object B,
then the caller retains ownership of B and should not destroy it until
A no longer needs it.

2. Crypto++ is thread safe at the class level. This means you can use
Crypto++ safely in a multithreaded application, but you must provide
synchronization when multiple threads access a common Crypto++ object.

Jeff


>>> dmye...@gmail.com 1/10/2006 6:52:00 PM >>>
I've had a number of issues with heap corruption using the
FIPS-certified
DLL.  I noticed the following in the documentation:


*** DLL Memory Management ***

Because it's possible for the Crypto++ DLL to delete objects allocated
by the calling application, they must use the same C++ memory heap.
Three
methods are provided to achieve this.
1.  The calling application can tell Crypto++ what heap to use. This
method
   is required when the calling application uses a non-standard heap.
2.  Crypto++ can tell the calling application what heap to use. This
method
   is required when the calling application uses a statically linked
C++
Run
   Time Library. (Method 1 does not work in this case because the
Crypto++
DLL
   is initialized before the calling application's heap is
initialized.)
3.  Crypto++ can automatically use the heap provided by the calling
application's
   dynamically linked C++ Run Time Library. The calling application
must
   make sure that the dynamically linked C++ Run Time Library is
initialized
   before Crypto++ is loaded. (At this time it is not clear if it is
possible
   to control the order in which DLLs are initialized on Windows 9x
machines,
   so it might be best to avoid using this method.)

When Crypto++ attaches to a new process, it searches all modules
loaded
into the process space for exported functions
"GetNewAndDeleteForCryptoPP"
and "SetNewAndDeleteFromCryptoPP". If one of these functions is found,
Crypto++ uses methods 1 or 2, respectively, by calling the function.
Otherwise, method 3 is used.

This all leads me to believe this is at the root of the issues I'm
encountering.  I've tried adding the following code to my application

#include "stdafx.h"
#include <dll.h>
#include <malloc.h>

using namespace CryptoPP;

#ifdef CRYPTOPP_IMPORTS

static bool cryptoppDllInitialized = false;
extern "C" __declspec(dllexport) void __cdecl
GetNewAndDeleteForCryptoPP(PNew &newFcn, PDelete &deleteFcn) {

#if 0
   newFcn = &operator new;
   deleteFcn = &operator delete;
#else
   newFcn = malloc;
   deleteFcn = free;
#endif
}
#endif

bool isFipsInitialized () {
   return cryptoppDllInitialized;
}

bool initializeFipsLibrary () {
   // Make sure the connections to the FIPS DLL are loaded and ready
   if (!cryptoppDllInitialized) {
       if (!FIPS_140_2_ComplianceEnabled()) {
           AfxMessageBox ("FIPS 140-2 compliance was turned off at
compile
time.", MB_ICONERROR);
           return false;
       }

       // check self test status

       PowerUpSelfTestStatus puts = GetPowerUpSelfTestStatus();

       if (puts != POWER_UP_SELF_TEST_PASSED) {
           AfxMessageBox ("Automatic power-up self test failed.",
MB_ICONERROR);
           return false;
       }

       cryptoppDllInitialized = true;
   }

   return true;
}

#endif


The above code is called out of my applications InitInstance code.
I've
tried seeting the new and delete functions to malloc/free and to the
operator new and delete.  In both cases, GetPowerUpSelfTestStatus
fails.  If
I don't provide the GetNewAndDeleteForCryptoPP function, then
GetPowerUpSelfTestStatus succeeds.  However, in that case the
application
has heap corruption issues.  If I don't release any of the memory I
allocate
then the vast majority of the heap issues go away but I'm not sure
they're
all gone and I'd rather not have my application leak memory.

Any ideas?  What is the right way to handle memory allocation?  Is
there a
reference I can go to that gives me more information?

Thanks in advance.

[Sujin Han]

I only need to use GenerateRSAKey, RSAEncryptString
and RSADecryptString from the cryptest. What are the
minimum header files I need?

And what's this custom build error when building in
VS.NET?

Creating library .\DLL_Release/cryptopp.lib and
object .\DLL_Release/cryptopp.exp
Performing Custom Build Step
Unrecognized command. Run "cryptest h" to obtain usage
information.
Project : error PRJ0019: A tool returned an error code
from "Performing Custom Build Step"

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[David Myers]

We found the issue that was causing all these problems. It turned out that
elsewhere in the code the was a problem with the handling of a ComBStr
object and that was introducing heap problems that showed up inside the
cryptopp operations.

[David Myers]

[Jeffrey Walton]

Hi dmyers,

This is also from the readme.txt. A lot of people miss it...

*** Important Usage Notes ***

1. If a constructor for A takes a pointer to an object B (except
primitive
types such as int and char), then A owns B and will delete B at A's
destruction. If a constructor for A takes a reference to an object B,
then the caller retains ownership of B and should not destroy it until
A no longer needs it.

2. Crypto++ is thread safe at the class level. This means you can use
Crypto++ safely in a multithreaded application, but you must provide
synchronization when multiple threads access a common Crypto++ object.

Jeff

>>> dmye...@gmail.com 1/10/2006 6:52:00 PM >>>

[David Myers]

We found the issue that was causing all these problems.  It turned out that elsewhere in the code the was a problem with the handling of a ComBStr object and that was introducing heap problems that showed up inside the cryptopp operations.

On 1/12/06, David Myers <dmye...@gmail.com> wrote: