So... Crypto++ and STLport (recent versions, anyway) don't mix all that
well. What I mean is that Crypto++ can NOT be used with STLport in the
"no iostreams" (_STLP_NO_IOSTREAMS) mode, which is its simplest case -
requiring only the STLport source and headers (no library needs to be
built).
If you try to use STLport in this mode with Crypto++, you get immediate
compile errors because STLport has detected Crypto++'s use of iostreams.
Since I like using STLport but am very pleased with the speed of
Crypto++ hashing functions, I looked for a solution... I decided to try
and build a Crypto++ "lite" version as a proof-of-concept. I will
present my results, and hope that either a) Wei agrees that this extra
packaging of Crypto++ has merit, or b) Wei (or anyone) explains an even
easier way to achieve my goals. ;)
Paraphrasing Wei's minimum hashing test code from a previous thread:
#define CRYPTOPP_ENABLE_NAMESPACE_WEAK 1
#include "md5.h"
#include "sha.h"
#include "whrlpool.h"
USING_NAMESPACE(CryptoPP)
USING_NAMESPACE(std)
int _tmain(int argc, _TCHAR* argv[])
{
Weak::MD5 md5;
SHA sha;
Whirlpool w;
byte a[100];
md5.CalculateDigest(a, a, 0);
sha.CalculateDigest(a, a, 0);
w.CalculateDigest(a, a, 0);
return 0;
}
I can build this with VS 2005 SP1 with settings similar to those used in
Crypto++ (with the addition of the linker "optimization" switch
"opt:nowin98") and get an exe size of 138 KB. When I substitute
"cryptlite.lib" for the standard "cryptlib.lib", this comes down to 84.5
KB. :)
I created "cryptlite.lib" by adding a "cryptlite" project to the
"cryptest" solution. It is [for now] just a static lib containing only
the files needed for the above hashing test code:
algparam.cpp, cpu.cpp, cryptlib.cpp, filters.cpp, md5.cpp, misc.cpp,
mqueue.cpp, queue.cpp, sha.cpp, and whrlpool.cpp. The ONLY source mod
required is blocking the "include <locale>" in stdcpp.h, which I
accomplished by wrapping said include with "#ifndef CRYPTOPP_LITE".
So for BUILDING this subset lib, just define this symbol in the
"cryptlite" project. When USING this lib, CRYPTOPP_LITE must be
defined, as well as CRYPTOPP_MANUALLY_INSTANTIATE_TEMPLATES - both
before the includes of the Crypto++ headers.
Why do we care about any of this? Since we can now use the desired
STLport "headers-only" mode with Crypto++, we can rebuild the above test
case, and we see... 84 KB. Big deal. BUT - let's look at a real app
which uses the above hashes plus a lot of STL:
RFtp PRO 3.2
============
727 KB baseline code using STLport and LibTomCrypt hashes
803 KB MS STL + cryptlib
760 KB MS STL + cryptlite
737 KB STLport + cryptlite
Things start looking a bit more appealing with more realistic tests. :)
Notice that, even aside from STLport considerations, the "cryptlite"
subset of Crypto++ may have a niche where size matters (e.g.,
embedded?). ;) Clearly, more of the standard Crypto++ modules could be
added - pretty much everything that doesn't require iostreams or
whatever the locale header is providing?
Finally, what's up with CRYPTOPP_MANUALLY_INSTANTIATE_TEMPLATES? I ask
because I notice that a lot of the space savings of the "cryptolite" lib
can be realized with the ordinary "cryptlib" plus this define in the
client code... note that this is really just an educational question,
since it does not solve the STLport conflict.
Comments?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
