> The ANSI X9.17 (3-key Triple DES) and X9.31 (AES) based generators > cannot be used after December 2015 That's from a mail of yours (Jeff) from 13.04.2015 (subject: SP800-90 Random Number Generators).
We have surpassed that date, so *in theory* even the fact that we have a X9.17 / X9.31 RNG is non-compliant, so non-compliance shouldn't be causing us a headache here. As for the options, I don't think (3) and (4) are really options, as we really want to have better code coverage (and less surprises in the future). Personally I'd prefer (2) (as was already implemented). Please also note the fact that the constructor and the actual random number generation behave differently in terms of how they use the time. The constructor does: ENCRYPT(ENCRYPT ( Buffer XOR TIME ) XOR CLOCK) The RNG does: ENCRYPT(BUFFER XOR ( TIME || CLOCK )) both expressions output into the datetimebuffer. BR JPM Am 10.01.2016 um 04:09 schrieb Jeffrey Walton: > I'm trying to cut-in some self tests for X917RNG. Generating 10K bytes > is producing about 90 Valgrind findings on uninitialized reads. > > I've got them tracked down to uninitialized data members dtbuf and > either randseed or m_deterministicTimeVector > (http://github.com/weidai11/cryptopp/blob/master/rng.h#L43): > > class CRYPTOPP_DLL X917RNG : public RandomNumberGenerator, public > NotCopyable > { > public: > ... > > private: > member_ptr<BlockTransformation> cipher; > const unsigned int S; // blocksize of cipher > SecByteBlock dtbuf; // buffer for enciphered timestamp > SecByteBlock randseed, m_lastBlock, m_deterministicTimeVector; > }; > > dtbuf is the "date and time" buffer and it is causing most of them. It > seems dtbuf is sized to the blocksize in the ctor, but then short > date/time writes occur. Finally, when dtbuf is encrypted, > uninitialized tail bytes are encrypted. > > I don't recall ANSI X9.17 or X9.31 generators being non-determinstic > like this. The block diagrams I have seen feed "date and time" into > the generator, and "date and time" was sufficiently large (i.e., the > size of the block size). See, for example, page 76 at > http://www.fi.muni.cz/~xkrhovj/inf/DODIS/dissertation_thesis.pdf. > > I don't know if the behavior is by design, or if it was an oversight. > However, I think we have three or four options: > > (1) Leave existing behavior, provide a suppression file > - retains potential entropy > - non trivial, uses mangled names > - each compiler gets a signature in the file > - most likely non-compliant > > (2) Memset the dtbuf > - loss of entropy > - no suppression file > - most likely compliant > > (3) Don't add the self-tests > - No X917RNG or AutoSeededX917RNG coverage > - High-level, Engineering/C&A defect > > (4) Do nothing > - Renders Valgrind useless > - False positives drown-out real issues > > Last, but not least, let's remember the Debian/Purify fiasco > (https://www.schneier.com/blog/archives/2008/05/random_number_b.html). > > So, how would you guys like to handle it? > > Jeff > -- > -- > 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. > --- > You received this message because you are subscribed to the Google > Groups "Crypto++ Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- 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. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
