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 [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-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 [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
Fri May 22 21:04:25 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-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)
