Robert Roessler wrote: > I am considering using Cpypto++ for the hashing (and possibly RSA-1024 > signature verification). As I have noticed the occasional bug fix > mentioned here, I pulled the SVN trunk source and set out to build it > with my VS 2005 SP1 installation. Note that I am also using the 5.1.3 > STLport release from April (the latest). > > For cryptopp, I did a "configure -c msvc8 --no-rtti", followed by a > Release build of the cryptest project in Visual Studio.
Maybe I now see why no one has had any comments: the above "configure" is from STLport, which I was forced to actually build because Crypto++ uses iostreams (my own use of STLport involves no iostreams, so I get to use it in "headers-only" mode) - but everything else is just about Crypto++. ;) > I encountered 2 compile-time errors that required source adjustments - > at least that is how *I* got around them... ;) > > In fipstest.cpp line #282, I forced the #if to always be FALSE, since > STLport doesn't seem to support ifstreams with wide filenames. > > In zdeflate.cpp line #388, I also forced the #if to always be FALSE (but > just because it seemed expedient). > > Finally, the following 8 warnings were issued: > > rng.cpp(108) : warning C4789: destination of memory copy is too small > twofish.cpp(69) : warning C4789: destination of memory copy is too small > seal.cpp(65) : warning C4789: destination of memory copy is too small > seal.cpp(65) : warning C4789: destination of memory copy is too small > algebra.cpp(122) : warning C4789: destination of memory copy is too small > algebra.cpp(122) : warning C4789: destination of memory copy is too small > algebra.cpp(293) : warning C4789: destination of memory copy is too small > algebra.cpp(293) : warning C4789: destination of memory copy is too small > > The validation run had no failures, and the benchmark run looked very > good relative to your posted Pentium 4 numbers... and not so great > compared to your Opteron numbers (I was using a Core 2 Duo @ 2.4 GHz) - > but my Whirlpool was better than the Opteron (63 vs 77). :) But I am still left with a bizarre situation where Crypto++ insists on using iostreams somewhere - and that seems to be just the library itself, even if I just build that without the test program? Weirder than this is an *apparent* serious lack of modularity... this translates to my app growing by almost 200KB, just using the md5, sha* and whirlpool hashes, and when compared to LibTomCrypt using the same hashes. So, IS the iostream stuff required by [only] the Crypto++ hashing code, and if so, can I do anything about it? AND, is there something I am missing config-option-wise that would help in just pulling in the parts of Crypto++ (and the C++ runtime libs) that I really want? 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. -~----------~----~----~----~------~----~------~--~---
