RE: patch: initialize randpool with zeroes

> Date: Fri, 11 Sep 2009 22:33:49 -0600
> Subject: Re: patch: initialize randpool with zeroes
> From: zookog@...
> To: weidai@...
> CC: cryptopp-users@...
>
> 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 <weidai@...> wrote:
> >
> > Thanks, I've incorporated your patch.
> >
> > --------------------------------------------------
> > From: "zooko" <zookog@...>
> > Sent: Thursday, June 04, 2009 1:23 PM
> > To: "Crypto++ Users" <cryptopp-users@...>
> > 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  zooko@...
> >>  * 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)
> >>
> >>
> >
> > --~--~---------~--~----~------------~-------~--~----~