patch: initialize randpool with zeroes

[zooko]

Folks:

Here is a patch to initialize the randpool with zeroes.  I know  
opinions might differ about the value of this.  If Wei Dai wants, I  
could make a variant that is controlled by a #define or something.

Regards,

Zooko

Fri May 22 21:04:25 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-05-23  
18:41:39.000000000 -0600
+++ new-release-5.6.0-plus-zookopatches/c5/randpool.cpp 2009-05-23  
18:41:41.000000000 -0600
@@ -19,6 +19,8 @@
  RandomPool::RandomPool()
  : m_pCipher(new AES::Encryption), m_keySet(false)
  {
+ memset(m_key, 0, 32);
+ memset(m_seed, 0, 16);
  }

  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 cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---


Fri May 22 21:04:25 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-05-23 18:41:39.000000000 -0600
+++ new-release-5.6.0-plus-zookopatches/c5/randpool.cpp 2009-05-23 18:41:41.000000000 -0600
@@ -19,6 +19,8 @@
 RandomPool::RandomPool()
  : m_pCipher(new AES::Encryption), m_keySet(false)
 {
+ memset(m_key, 0, 32);
+ memset(m_seed, 0, 16);
 }
 
 void RandomPool::IncorporateEntropy(const byte *input, size_t length)

[Zooko O'Whielacronx]

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)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---

[Wei Dai]

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)
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---

[Zooko O'Whielacronx]

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)
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---

[Wei Dai]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I think I haven't checked it in yet. It should be sitting in my development desktop machine (which is currently down due to a blown power supply). I'll check it in once I get the machine fixed.

> 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)
> >>
> >>
> >
> > --~--~---------~--~----~------------~-------~--~----~

You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---