Does Endianness matter in NIST SP800-22 test?

Question

I am curious about Randomness test suite.

One of the famous randomness test suite, DIEHARDER, said that Endianness does not matter for a "GOOD" random generator.

Note that this is not the same as writing raw floating point numbers (that will not be random at all as a bitstream) and that "endianness" of the uints should not matter for the null hypothesis of a "good" generator, as random bytes are random in any order.

Just a rough guess, I think there is no difference between Big-endian and Little-endian in Randomness test. Because Randomness test is about counting the number of 0 or 1, checking pattern of bitstream, etc. (I read the whole paper, NIST SP800-22 revision 1a.)

But there is no written document in NIST SP800-22 that "Endianness doesn't affect the purpose of Randomness test".

Question.

1. Is there any missing part that saying "Endianness doesn't matter" in NIST SP800-22 paper?

2. Can I test Randomness without thinking of Endianness?

Why I got this question.

There is good example of Dieharder input file and NIST SP800-22 input file in data/data.pi with ASCII character.

And also I found out that Dieharder read file(ASCII) as Little-Endian and NIST read file(ASCII) as Big-Endian. You can see in stackoverflow how I found out.

However, due to Endianness, I have to make two output files. One is Big-Endian and the other one is Little-Endian. This could be waste of time and memory. So I wonder that "Does Endianness matter in NIST SP800-22 test suite?"

Answer 1

Endianness¹ can affect the result of a randomness test, and change a result from pass to fail, or vice versa (throwing a different run of the generator can have the same effect, to a somewhat lesser degree). However, if endianness significantly affects the outcome of the test, then (assuming the test is correct and correctly used)

• the generator is broken, since one of the to versions significantly fails the test, and any fixed swap of bits at the output of a generator indistinguishable from random yields a generator indistinguishable from random
• and the test is sensitive to a minor reordering of it's input, which is an indication of an overspecialized test.

My advise is thus to ignore the issue of endianness in the input of randomness tests.

Rather, question the motivation of running Dieharder or NIST SP800-22. It's customary in substandard crypto papers, especially those illustrating visually what encryption does to Lena. But success of such test is not an argument or (worse proof/demonstration) of the quality of some encryption, or PRNG, or TRNG incorporating a postprocessing state. Towards this, an analysis of the method used in the encryption, PRNG, or source+postprocessing of a TRNG, is necessary.

---

¹ That is the big-endian, little-endian, or other-endian order of bits in bytes, words or integers at output of the generator tested, and/or at input of the test program. For example, the NIST Statistical Test Suite's function convertToBits (file src/utilities.c here) converts bytes to bits per big-endian convention (contrary to the most common order in asynchronous serial communication). That matters in theory if an implementation of a generator that is mathematically defined to output a bitstream (e.g. A5-1) has it's production passed to that test in byte mode for efficiency.

Answer 2

Absolutely not.

I recommend you that writing[sic] binaries in Little-Endian.

That's irrelevant to the 800-22 suite. You have to consider what endianness means. Endianness is the order or sequence of bytes of a word of digital data. This suite does not use words. It uses octets.

The relevant part of the test documentation is:-

5.4.1 Data Input Data input may be supplied in one of two ways. If the user has a stand-alone program or hardware device which implements a RNG, the user may want to construct as many files of arbitrary length as desired. Files should contain binary sequences stored as either ASCII characters consisting of zeroes and ones, or as binary data where each byte contains eight bits worth of 0’s and 1’s. The NIST Statistical Test Suite can then independently examine these files.

and from the test suite itself:-

   Input File Format:
    [0] ASCII - A sequence of ASCII 0's and 1's
    [1] Binary - Each byte in data file contains 8 bits of data

   Select input mode:  

So you see that endianness has no relevance. It does not expect short/long integers nor floating point numbers. Other suites might though. You either input one byte ASCII data for 0 and 1, or you input (one hopes) uniformly distributed bits within octets.

---

Note: Not an expert on UTF encoding, but you can generate ASCII characters with forced non UTF-8 encoding. That might cause all tests withInput File Format: [0] ASCII to fail.