Hi, I was just using valgrind on Crypto++ again (as part of wondering why pycryptopp bug #19 wasn't taking effect on my Athlon64 Linux box) and I see that my patch to initialize randpool with zeroes is not in the current SVN trunk.
Regards, Zooko tickets mentioned in this letter: http://allmydata.org/trac/pycryptopp/ticket/19 # Segmentation fault in HashMultipleBlocks On Thu, Jun 4, 2009 at 4:02 PM, Wei Dai <[email protected]> wrote: > > Thanks, I've incorporated your patch. > > -------------------------------------------------- > From: "zooko" <[email protected]> > Sent: Thursday, June 04, 2009 1:23 PM > To: "Crypto++ Users" <[email protected]> > Subject: Re: patch: initialize randpool with zeroes > >> >> Jeffrey Walton suggested an improvement to this patch. Here's the new >> version, which I'm now using in pycryptopp and which seems to work >> fine. I would recommend a patch like this for Crypto++ trunk. If Wei >> Dai doesn't want to spend the CPU cycles and to eliminate the >> (questionable) bits of entropy to be found in uninitialized memory, >> then perhaps we could guard it with some sort of #define like >> "PURIFY_CLEAN"/"VALGRIND_CLEAN" or "INITIALIZE_RANDPOOL". >> >> Regards, >> >> Zooko >> >> HACK rgnt1-210-206-dhcp:~/playground/pycryptopp/cryptopp/release-5.6.0- >> plus-zookopatches$ darcs diff -u -p'initialize the randpool' >> Thu Jun 4 07:41:58 MDT 2009 [email protected] >> * initialize the randpool with zeroes instead of using whatever bits >> were there >> This makes valgrind stop complaining about using uninitialized >> memory. There are other ways to make valgrind stop complaining, such >> as by explicitly telling it "See these here bytes? Pretend from now >> on that they are initialized.", but I don't like using uninitialized >> memory for my randpool anyway. If my randpool is broken, I would like >> for it to start giving the exact same output time after time (or a >> short cycle, or a selection from a small set, or whatever), so that >> the users and developers can more quickly detect the problem, rather >> than rely for my security on the values in the uninitialized memory, >> which might not be all that unpredictable. >> diff -rN -u old-release-5.6.0-plus-zookopatches/c5/randpool.cpp new- >> release-5.6.0-plus-zookopatches/c5/randpool.cpp >> --- old-release-5.6.0-plus-zookopatches/c5/randpool.cpp 2009-06-04 >> 14:18:46.000000000 -0600 >> +++ new-release-5.6.0-plus-zookopatches/c5/randpool.cpp 2009-06-04 >> 14:18:46.000000000 -0600 >> @@ -19,6 +19,8 @@ >> RandomPool::RandomPool() >> : m_pCipher(new AES::Encryption), m_keySet(false) >> { >> + memset(m_key, 0, m_key.size()); >> + memset(m_seed, 0, m_seed.SizeInBytes()); >> } >> >> void RandomPool::IncorporateEntropy(const byte *input, size_t length) >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
