Hi Glen, I'm at a loss. Here's where I would look next. StringSource offers two ctors. At the next explosion, could you jump from the first to the second? I'm thinking that the compiler may be choosing the wrong constructor (I've forced a bad choice in the past), or the assumption of '\0' termination is incorrect.
I believe when using the second, you will need to add a cast (in addition to the length): StringSource( (const byte*)in_str.c_str(), in_str.length(), true, new Base64Encoder( new StringSink(out_val),false)); At minimum, I would expect it to ease the use of a SecByteBlock. A SecByteBlock is a typedef of SecBlock. See http://cryptopp.com/docs/ref/class_sec_block.html. SecByteBlock offers both BytePtr() and SizeInBytes(). They should allow you to use the SecByteBlock in place of the std::string: SecByteBlock block; ... StringSource( block.BytePtr(), block.SizeInBytes(), true, new Base64Encoder( new StringSink(out_val),false)); Jeff // zero terminated string as source StringSource (const char *string, bool pumpAll, BufferedTransformation *attachment=NULL) // binary byte array as source StringSource (const byte *string, size_t length, bool pumpAll, BufferedTransformation *attachment=NULL) On 3/5/08, Glen Miller <[EMAIL PROTECTED]> wrote: > > I think VS2008 might be a red herring at this point. The change in > behavior occurs when upgrading from Crypto++ 5.1 to 5.5.2 (both under > VS2003). I am running WinXP. > > Interestingly, the following code works as expected (although in my > test case the input string is different, so I'm not 100% sure). If I > can convert the SecByteBlock data from my previous post into a string, > I can probably pass it to this function as a workaround. Is this > possible? > > string convert_to_base64(const std::string &in_str) > { > string out_val; > StringSource(in_str.c_str(), true, new Base64Encoder( new > StringSink(out_val),false)); > return out_val; > } > > On Mar 5, 3:47 pm, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote: > > Hi Glen, > > > > Forgive my ignorance... I overlooked VS2008 with whatazor. I don't > > have VS 2008 or Vista to confirm, so take this with a grain of salt. > > > > > Yes, I rebuilt the Crypto++ LIB and my wrapper DLL under VS2008. > > > > It appears VS2008 and LIB used in a DLL causes problems. Did you use > > the /dynamicbase linker option? Can you confirm the problem when not > > using ASLR (is this possible??)? > > > > Finally, is this Vista specific? If so, the /dynamicbase linker option > > was added in VS 2005, SP1. Can anyone confirm the issue using Vista/VS > > 2005 SP1? > > > > Jeff > > > > On 3/5/08, Glen Miller <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Hi Andy, > > > > > Thanks for your reply. > > > > > Yes, I rebuilt the Crypto++ LIB and my wrapper DLL under VS2008. When > > > it wasn't working as expected, I built 5.5.2 under VS2003 and re-tried > > > with the original code and noticed the exception. > > > > > You are right - I once tried to call the VS2003 version of my wrapper > > > DLL from VS2008 and really nasty things happened. > > > > > On Mar 5, 2:54 pm, Andy Finkenstadt <[EMAIL PROTECTED]> wrote: > > > > This may sound naive, but were your binaries of CryptoPP re-compiled > > > > under the VS2008 environment? The .LIB is compiler-version and -options > > > > and STL-version specific, and mixing them will result in much > > > > unhappiness and similar issues like these below. > > > > > > --andy > > > > > > Glen Miller wrote: > > > > > I'm having what appears to be the same problem with StringSource. The > > > > > following function works with Crypto++ 5.1 in VS2003, but does not > > > > > work with Crypto++ 5.4 or 5.5.2. In VS2003, it throws an exception. In > > > > > VS2008 no errors occur, but "signature" is not populated. I'm > > > > > upgrading our code to VS2008, and am stuck at this point - since > > > > > Crypto > > > > > ++ 5.1 does not work under VS2008. Is there a work-around? > > > > > > > int rsa_sha1_sign( const string &key, const string &plaintext, string > > > > > &signature) > > > > > { > > > > > try > > > > > { > > > > > AutoSeededRandomPool rng; > > > > > > > RSASSA_PKCS1v15_SHA_Signer privkey(StringSource(key, true, new > > > > > Base64Decoder())); > > > > > > > SecByteBlock sbbSignature(privkey.SignatureLength()); > > > > > > > privkey.SignMessage(rng, (byte const*) plaintext.data(), > > > > > plaintext.size(), sbbSignature.begin()); > > > > > > > StringSource source(sbbSignature, true, new Base64Encoder(new > > > > > StringSink(signature),false)); > > > > > } > > > > > catch(CryptoPP::Exception) > > > > > { > > > > > return 0; > > > > > } > > > > > return 1; > > > > > } > > > > > > > On Feb 29, 7:22 am, whatazor <[EMAIL PROTECTED]> wrote: > > > > > > >> Hi, > > > > >> I've used this code (but the difference is only that the class is > > > > >> instanciated internally to function brackets) and the behaviour > > > > >> doesn't change. > > > > > > >> :( > > > > > > >> On 25 Feb, 00:23, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote: > > > > > > >>> Hi w, > > > > > > >>> I suspect it has to with your usage of the library. Try the > > > > >>> following. > > > > > > >>> Jeff > > > > > > >>> #include <iostream> > > > > >>> #include <string> > > > > > > >>> using std::string; > > > > >>> using std::cout; > > > > >>> using std::endl; > > > > > > >>> #include "default.h" > > > > >>> #include "filters.h" > > > > > > >>> using CryptoPP::DefaultEncryptorWithMAC; > > > > >>> using CryptoPP::DefaultDecryptorWithMAC; > > > > >>> using CryptoPP::StringSink; > > > > >>> using CryptoPP::StringSource; > > > > > > >>> int main(int argc, char* argv[]) > > > > >>> { > > > > >>> string message = "secret message"; > > > > >>> string password = "password"; > > > > >>> string encrypted, recovered; > > > > > > >>> StringSource( > > > > >>> message, > > > > >>> true, > > > > >>> new DefaultEncryptorWithMAC( > > > > >>> password.c_str(), > > > > >>> new StringSink( encrypted ) > > > > >>> ) // DefaultEncryptorWithMAC > > > > >>> ); // StringSource > > > > > > >>> StringSource( > > > > >>> encrypted, > > > > >>> true, > > > > >>> new DefaultDecryptorWithMAC( > > > > >>> password.c_str(), > > > > >>> new StringSink( recovered ) > > > > >>> ) // DefaultDecryptorWithMAC > > > > >>> ); // StringSource > > > > > > >>> cout << "Recovered Text:" << endl; > > > > >>> cout << " " << recovered << endl; > > > > > > >>> return 0; > > > > > > >>> } > > > > > > >>> On 2/22/08, whatazor <[EMAIL PROTECTED]> wrote: > > > > > > >>>> Hi All, > > > > >>>> I use crypto 5.4 and I notice a strange problem using an automated > > > > >>>> test for testing a wrapping class of StringSource I have. This > > > > >>>> wrapping class only call StringSource, but the problems is that > > > > >>>> sometimes (not regularly) StringSource throw an exception even if > > > > >>>> this > > > > >>>> automated test use always the same string to crypt and then > > > > >>>> decrypt, > > > > >>>> and the same passphrase > > > > > > >>>> try > > > > >>>> { > > > > >>>> StringSink *ssink = new StringSink(out); > > > > >>>> DefaultEncryptorWithMAC * mac = new > > > > >>>> DefaultEncryptorWithMAC(passPhrase, ssink); > > > > > > >>>> StringSource s((const byte *)in, len, true, mac); > > > > >>>> } > > > > >>>> catch (...) > > > > >>>> { > > > > >>>> result = false; > > > > >>>> } > > > > > > >>>> where is the problem? > > > > > > >>>> thx you very much > > > > >>>> w- Hide quoted text - > > > > > > >> - Show quoted text -- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
