Score:1

Crypto

Does Endianness matter in NIST SP800-22 test?

TyeolRik

1/30/23, 9:56 AM

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.

Is there any missing part that saying "Endianness doesn't matter" in NIST SP800-22 paper?
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?"

107

0 + 0

statistical-test

randomness

pseudo-random-generator

Score:1

Crypto

fgrieu

1/30/23, 11:06 AM

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.

0 + 0

TyeolRik

1/30/23, 11:48 AM

Thanks to your advise, ```ignore the issue of endianness```. I agree with "analysis of the method, PRNG, is necessary" :)

Paul Uszak

1/30/23, 2:12 PM

Suggest removal/ammendment of _"TRNG"_ bit. Post processing may be a vN extractor, CRC-16 or simple matrix multiplication. No crypto primitives are necessary, and indeed dangerous. A randomness test is therefore the ultimate and final arbitrator for correct operation. I suggest that the only substandard TRNG papers are those without a final randomness test. That's why all decent papers have them at the end.

Paul Uszak

2/1/23, 12:40 PM

It can't affect this specific suite, as SP800-22 doesn't use words.

fgrieu

2/1/23, 2:00 PM

@Paul Uszak: see new note ¹ written following your last comment.

Paul Uszak

2/2/23, 9:34 PM

Err, still don't quite see your point. A test pass would occur with a uniform distribution of set bits in all the bytes, irrespective of bit endianness. Test passing data supplied via RS-232 would look just like `\dev\urandom` output...

Score:0

Crypto

Paul Uszak

1/30/23, 1:29 PM

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.

0 + 0

TyeolRik

2/1/23, 5:41 AM

I don't think so. Your answer is about ASCII, but Endianness is different thing with ASCII. As you can see in NIST test suite, there is ```data/data.pi``` file which is for example. And there is 0 and 1, binaries coded ASCII. But when you convert this data into Bytes (Binary file) Data should be different because Endianness is about "the Way of writing Binaries." So, I am afraid your answer is irrelevant. But thank you for your interest and discussion :)

Paul Uszak

2/2/23, 9:23 PM

@TyeolRik You realise that the lines of `data/data.pi` are not integers? There are just zeros and ones, with some line breaks to make it look pretty. Hence my answer (in my opinion) is spot on.

TyeolRik

2/4/23, 7:15 PM

// I am afraid but ```data/data.pi``` is not Integers. According to [this page](https://www.exploringbinary.com/pi-and-e-in-binary/), the PI, 3.142592...., is ```11.00100100001111...``` in Binary. And the file ```data/data.pi``` is also ```11.00100100001111...```. So, I guess binaries in ```data/data.pi``` are just PI not integers. :)

TyeolRik

2/4/23, 7:19 PM

Oops. Sorry for misunderstanding your words. (Due to my short of English) We are on the page. Thank you for your advice which is added. ```writing binaries in Little-Endian```