Re: Question about FIPS dll usage and util functions

[Wei Dai]

You can build a static library that contains only code that are not in the
DLL, by building the "DLL-Import Debug" or "DLL-Import Release"
configuration instead of the "Debug" or "Release" configuration. Then you
can link your application with both the DLL and the static library.

----- Original Message -----
From: "Nick42" <nick.ca...@gmail.com>
To: "Crypto++ Users" <cryptop...@googlegroups.com>
Sent: Monday, August 20, 2007 4:28 PM
Subject: Question about FIPS dll usage and util functions

>
> I've been using crypto++ as a static lib for a while, and am trying to
> convert to use as a FIPS certified dll. However, only some of the
> objects are included in the FIPS dll, and we are using some of the
> others also, which is causing linking to fail.
>
> Is there a suggested way to link both the FIPS certified dll and the
> extra utility code? I didn't see a lib with only the utility code. Has
> anyone else attempted this, and/or is there something easy I'm missing?
>
>
> >

[Nick42]

Thanks for the response... I saw this after I posted, and got it
working (well, linking at least), but I have a followup question:

I have not been able to get the memory management working. I am
statically linking the C runtime, and have tried defining
GetNewAndDeleteForCryptoPP, but I'm not sure how it needs to be
defined such that cryptopp can pick it up, and I can't find any
example of how to define it in the cryptest project. I would prefer to
tell cryptopp the new/delete functions to use, in case in the future I
have other libraries linking this way, to prevent conflicts.

Is there example code on how to implement this function somewhere, or
any magic, or something which will not work with how I'm trying to use
it?

Also, as a side note, I get the following error compiling the cryptdll
project from the 5.3 FIPS code with VS2005:
2>.\integer.cpp(88) : error C2244:
'CryptoPP::AlignedAllocator<T>::allocate' : unable to match function
definition to an existing declaration
2> [...]\cryptopp_5_3_fips\include\integer.h(44) : see
declaration of 'CryptoPP::AlignedAllocator<T>::allocate'
2> definition
2> 'AllocatorBase<T>::pointer
CryptoPP::AlignedAllocator<T>::allocate(CryptoPP::AlignedAllocator<T>::size_type,const
void *)'
2> existing declarations
2> 'T
*CryptoPP::AlignedAllocator<T>::allocate(CryptoPP::AlignedAllocator<T>::size_type,const
void *)'

Not a big deal since I want to use the FIPS certified pre-compiled DLL
anyway, but thought I'd post it in case it's not a known issue.

- Nick

[Wei Dai]

If you're using a static C++ runtime library, then you have to use "method
2" as the Readme.txt says:

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.)

This means you need to use "SetNewAndDeleteFromCryptoPP", which has an
example in dlltest.cpp.

[Nick42]

This doesn't appear to work if I'm linking to the MFC library
statically also, as I get conflicts with the new and delete symbols
already defined (in this case, within the MFC library). There doesn't
seem to be a way to make this work without dynamically linking
everything (unless I'm missing something).

- Nick

[Jeffrey Walton]

Hi Nick,

> (unless I'm missing something).

I believe you have not found the correct hoop to jump through. Perhaps
create a second project which uses Crypto++ as a static Dll that
imports the missing functions. Create this project as a DLL, and place
the header in it's own namespace. I've never tried it myself at this
point, but I've pondered the solution in the past.

> There doesn't seem to be a way to make this
> work without dynamically linking

I beleive you are correct... Mixing and matching (though required) is
diffcult to do.

In the past I had a Document/View architecture. The Doc/View
architecture used an iterator to to enumerate docs. However, becuse
STL/Crypto++ had the same named iterators, all hell broke loose.

In the end, I used a linker switch (NODEFAULTLIB) to ease the pain.
However, I would get obscure errors every now and again. For example,
If the EXE were copied to a Network drive and run from the location, a
Date/Time control would not initialize properly and crash the
application. See
http://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/thread/cbad8aa7d0ad6b13/6a0c404c1124ed82?lnk=st&q=%22jeffrey+Walton%22+ordinal&rnum=1#6a0c404c1124ed82

Sorry I could not be of more help.

Jeff

[Nick42]

So after fighting with this for a few days, I think I'm going to give
up, and tell our customers we can't give them a version of our apps
which uses the FIPS certified version of cryptopp.

The option 2 solution doesn't work, because the function never gets
called. I have no idea if this is a loading order issue, or a naming/
calling convention issue, or something else; there is no working
example I can find of this method (the dll.cpp shows the calling usage
from within the DLL, but not how to define it within an application).

Even if I could get that working, I can't explicitly define new/delete
without dynamically linking MFC, because of conflicts. I also can't
figure out the syntax to use placement new to use the allocator from
cryptopp to create object to pass to the DLL. Basically, it appears to
be unusable without static linking everything, or dynamic linking
everything.

On Aug 23, 11:17 am, "Jeffrey Walton" <noloa...@gmail.com> wrote:
> Hi Nick,
>
> > (unless I'm missing something).
>
> I believe you have not found the correct hoop to jump through. Perhaps
> create a second project which uses Crypto++ as a static Dll that
> imports the missing functions. Create this project as a DLL, and place
> the header in it's own namespace. I've never tried it myself at this
> point, but I've pondered the solution in the past.
>
> > There doesn't seem to be a way to make this
> > work without dynamically linking
>
> I beleive you are correct... Mixing and matching (though required) is
> diffcult to do.
>
> In the past I had a Document/View architecture. The Doc/View
> architecture used an iterator to to enumerate docs. However, becuse
> STL/Crypto++ had the same named iterators, all hell broke loose.
>
> In the end, I used a linker switch (NODEFAULTLIB) to ease the pain.
> However, I would get obscure errors every now and again. For example,
> If the EXE were copied to a Network drive and run from the location, a
> Date/Time control would not initialize properly and crash the

> application. Seehttp://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/...

>
> Sorry I could not be of more help.
>
> Jeff
>

[Jeffrey Walton]

Hi Nick,

> So after fighting with this for a few days, I think I'm going to give
> up, and tell our customers we can't give them a version of our apps
> which uses the FIPS certified version of cryptopp.

Perhaps, but perhaps not.

Send over a minimum project skeleton which exhibits the behavior. I
will get it working for you this weekend. It is time to try out my
past speculations.

What Development Environment? My test lab (at the house) has the
following available:

VC++ 6.0 Enterprise
Visual Studio 7.0 (no 7.1)
Visual Studio 8.0

Keep in mind I am a System Administrator and Security Engineer. I
program for fun (and the challenge). Money is not in the picture yet
:)

With that said, I should be able to make headway on it. And I have
others who are programming resources I can call on when I hit a brick
wall.

It is something that needs to be added to 'Compiling and Integrating
Crypto++ into the Microsoft Visual C++ Environment'
(http://www.codeproject.com/tips/CryptoPPIntegration.asp). I just
haven't had the time to set up test cases to find the work around.

Jeff
noloader, gmail account

On 8/23/07, Nick42 <nick.ca...@gmail.com> wrote:
>

[Wei Dai]

But there is an example of method 2 in dlltest.cpp, as I mentioned.

If you can't get method 2 to work, you can try method 3. That is, switch to
using DLL form of MFC and C++ run time, and let Crypto++ get the new and
delete functions directly from the C++ runtime DLL. There's no reason why
you can't use the DLL form of C++ runtime library and still link with both
the static and DLL Crypto++.

[Nick42]

Hard to construct a snippet by stripping out enough stuff, but I'll
post the basics of what I have. I'm using VS 8.0, Win32 app with MFC
(static link).

Basically, I have this class (modify macro for your favorite singleton
type, or convert to static members as appropriate):

DECLARE_SINGLETON_CLASS( CCryptoppMemoryManagement )
{
public:
CCryptoppMemoryManagement(void);
virtual ~CCryptoppMemoryManagement(void);

CryptoPP::PNew m_pNew;
CryptoPP::PDelete m_pDelete;
CryptoPP::PSetNewHandler m_pSetNewHandler;
};

I'm trying to define the global function SetNewAndDeleteFromCryptoPP
such that I can populate the member variables of this class, and then
I can use them when doing any allocations which cross the DLL
boundary, probably using placement new (which I did get working after
my last post), along the lines of:

#define CPPNew( CClassType ) new
( CCryptoppMemoryManagement::GetInstance().m_pNew( sizeof( CClassType ) ) )
CClassType

With usage as:

CClassType* pInstance = CPPNew( CClassType )( constructor_arguments );

I think this should work, given the global function sets the pointers
in the singleton correctly.

This is my global function definition:

void SetNewAndDeleteFromCryptoPP( CryptoPP::PNew pNew,
CryptoPP::PDelete pDelete, CryptoPP::PSetNewHandler pSetNewHandler )
{
TRACE( _T("SetNewAndDeleteFromCryptoPP called\n") );

CCryptoppMemoryManagement::GetInstance().m_pNew = pNew;
CCryptoppMemoryManagement::GetInstance().m_pDelete = pDelete;
CCryptoppMemoryManagement::GetInstance().m_pSetNewHandler =
pSetNewHandler;
}

As far as I can tell, the function is never called (symbols are not
even loaded for it if it's in a library; I tried defining the function
both on the wrapper static library and in the main exe code, neither
worked).

Is this enough to see what I'm doing? It would take a lot of work to
strip it down to a skeleton project, just due to common macros and
such, so hopefully this is understandable.

Thanks for looking into it. :)

PS: I have another idea I'm going to try (I don't like to give up,
despite frustration)... if I can manually extract the pointers for the
cryptopp.dll 's memory management functions using the same methods in
dll.cpp, I can probably alleviate the need to have a callback function
in the global space which isn't being called, and just populate on
first hit of my singleton code (at which point the DLL will be
loaded). I'll let you know if it works.

- Nick

On Aug 23, 4:15 pm, "Jeffrey Walton" <noloa...@gmail.com> wrote:
> Hi Nick,
>

> > So after fighting with this for a few days, I think I'm going to give
> > up, and tell our customers we can't give them a version of our apps
> > which uses the FIPS certified version of cryptopp.
>
> Perhaps, but perhaps not.
>
> Send over a minimum project skeleton which exhibits the behavior. I
> will get it working for you this weekend. It is time to try out my
> past speculations.
>
> What Development Environment? My test lab (at the house) has the
> following available:
>
> VC++ 6.0 Enterprise
> Visual Studio 7.0 (no 7.1)
> Visual Studio 8.0
>
> Keep in mind I am a System Administrator and Security Engineer. I
> program for fun (and the challenge). Money is not in the picture yet
> :)
>
> With that said, I should be able to make headway on it. And I have
> others who are programming resources I can call on when I hit a brick
> wall.
>
> It is something that needs to be added to 'Compiling and Integrating
> Crypto++ into the Microsoft Visual C++ Environment'
> (http://www.codeproject.com/tips/CryptoPPIntegration.asp). I just
> haven't had the time to set up test cases to find the work around.
>
> Jeff
> noloader, gmail account
>

[Nick42]

Ug. Got the dynamic load to work, but the function call still isn't
working, and I suspect it might be an issue with the interaction with
the standard cpp library (which I may not be able to work around).
Basically, I have this call (using my previous macro):

std::string newKey; // pre-populated to encoded key value

std::string decodedKey;
CryptoPP::StringSource(newKey, true, CPPNew( CryptoPP::HexDecoder )
( CPPNew( CryptoPP::StringSinkTemplate<std::string> )(decodedKey)));

This is failing with a memory error, but I think it's related to
std::string, because I can use my CPPNew macro to allocate an
arbitrary class now, and it's working. I'm starting to think the
wrapping the whole thing behind a DLL boundary (which is dynamically
loaded and dynamically linked) might be the only tenable solution. =/

> ...
>
> read more »