I haven't actually tested for memory leaks but the code below will not be correct if you have several threads that use the cryptographic library - then you can't share the random generator across threads. I'm not at all a cryptographic expert but I've noticed that several interfaces use random generators but the actual implementation does not use it. Then it would of course be safe to use a static one - but the code would in an effect be "wrong" since one is breaking the "contract" of the interface.
Why would you reseed the random generator each call? There can be a big performance penalty for that. Would it really strengthen security or is it "just is case..." Third, does the memory corruption occur in both static library and dll versions? And please post a working sample that produces the corruption then we would at least be analyzing the same code... perhaps from different angles (I'm using statically linked libraries) /svante karlsson -----Original Message----- From: James Vanns [mailto:[EMAIL PROTECTED] Sent: den 21 juni 2005 10:37 To: [email protected] Subject: RE: Memory Leak How about using a [static inline?] function that itself holds a static PRNG object that you simply re-seed with each call? Something like this: static inline RandomNumberGenerator& PSRNG (void) { static AutoSeededRandomPool rng; rng.Reseed (); return rng; } Then call this function (PSRNG ()) from your loop? Would that help? Its not creating/destroying a new object all the time just returning a reference to an already instantiated object (re- seeded). Regards Jim Vanns On Mon, 2005-06-20 at 16:34 -0700, Newman, Christofer wrote: > Leaking isn't really the problem. I could handle a little leaking to get > "free" crypto. I can't handle memory corruptions. Just try creating most > crypto objects (such as an instance of > CryptoPP::AutoSeededX917RNG<CryptoPP::AES>) in a loop. You'll get a > crash long before you've run out of memory. This happens with so many > objects that it makes it quite difficult to get things done. > > -Chris > > -----Original Message----- > From: James Vanns [mailto:[EMAIL PROTECTED] > Sent: Monday, June 20, 2005 4:17 AM > To: [email protected] > Subject: RE: Memory Leak > > This is quite alarming. Does anyone have any indication as to [exactly] > where the memory leak(s) is/are? I also have code (going live date > approaching) that uses Crypto++' RSASS implementation. > > Jim > > On Wed, 2005-06-15 at 08:53 +0800, ZENG Ke wrote: > > I have the same observation, cryptopp causes severe memory leak. > > > > > -----Original Message----- > > > From: Newman, Christofer [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, June 15, 2005 8:48 AM > > > To: [email protected] > > > Subject: RE: Memory Leak > > > > > > From what I've been able to tell, that's exactly where the memory > > > leak is. We've had to stop using cryptopp for signing and > > > verification. I've posted twice asking for help. I hope you have > > > beter luck. I'll be watching the board. > > > > > > -Chris > > > > > > -----Original Message----- > > > From: Seshu Madabushi [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 14, 2005 3:33 PM > > > To: [email protected] > > > Subject: Memory Leak > > > > > > All > > > > > > I am using cryptopp.dll (FIPS version) to do signing and > > > verification process. When debugging my application through Bounds > > > Checker I noticed that memory leaks. Below is the code snippet I am > > > using for signing. Can anyone please explain whether the leak is in > CryptoPP? > > > > > > StringSource privFile(prvkey1,len,true, NULL); > > > RSASSA_PKCS1v15_SHA_Signer priv(privFile); > > > priv.SignMessage(GlobalRNG(), (byte *) DigestValue, TotDigestLen , > > > (byte *) signature); > > > > > > Thanks > > > Seshu > > > > > > > > > > -- > James Vanns BSc (Hons) MCP > Linux Systems Administrator > Software Engineer (Linux / C & C++) > Canterbury Christ Church University College Public Key: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x24045370 > > > -- James Vanns BSc (Hons) MCP Linux Systems Administrator Software Engineer (Linux / C & C++) Canterbury Christ Church University College Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x24045370
