ANSI X9.17 RNGs and random stack/heap data?

[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

[Jeffrey Walton]

  (2) Memset the dtbuf
        - loss of entropy
        - no suppression file
        - most likely compliant

In this case, we opted for a memset of the tail bytes in the timestamp buffer. According to the X9.31 spec, the security of the generator lies in the key, and not the timestamp. The timestamp is used to help ensure non-reuse of a security context. Also see http://crypto.stackexchange.com/q/634.

I have not been able to locate the X9.31 test vectors. I see them mentioned frequently; I just have not been able to locate the actual vectors. Once we have them in hand, we may know more about handling of the buffer or how to cope with a timestamp that is smaller than the block size.

The check-in was committed at https://github.com/weidai11/cryptopp/commit/76b2f9387d686ea4a880c820b4de0bca7214839c .

Jeff

[Jean-Pierre Münch]

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

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
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 cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Walton]

On Sunday, January 10, 2016 at 3:23:36 PM UTC-5, jean-pierre.muench wrote:

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.

Well, as far as I know, the X9 generators are no longer allowed in US Federal. I'm not aware of them being withdrawn in other places, like US Financial or Automotive, but I have not done work in the vertical in a couple of years.

Does anyone know if the ANSI X9 committee deprecated them, too?

Jeff