# NIST Statistical Test Segmentation Fault (Core dumped)

I am trying to use NIST Statistical Test

When I have 1 line number which is includes 7467 character,(all of the are either 1 or 0) the test is working I am following these steps: ./assess 7467, then press 0 and write my file name, then press 1, then press 0 to continue, then for how many bit streams, I am pressing "1" since it has 1 line and it is working. However when I do it for separete my file to equal lines which each of them include 100 character, like that: the test is completed but with "Segmentation fault (core dumped )"message

I don't know why I am getting this error. Maybe I am running program wrong, or maybe my input file format is bad By the way, for diharder we should have too many numbers but for NIST do we have limitations? Accordin to NIST tutorail each sequence/stream should be at least 100 charachter but except that I didnt see anything Any suggestions/ ideas

Update (by way of moderator)

Can you please explain how can you try data.pi? Because when I tried I have still the same error. I am doing this steps:

./asses 24 (because each line have 24 characters in the data.pi except first line)

Secondly I am pressing 0 for entering the file name

Thirdly I am writing data pi and I am pressing 1

Then I am pressing zero

Finally I am entering the number of bitstream and file includes 40000 lines (a bit more than 40000 but I am writing 40000)

Then I have this result:

• Maybe they don't allow (certain) line endings or only allow a certain kind of white space to be present. Note that these kind of tools are created by cryptographers / mathematicians, and cryptographers / mathematicians are not necessarily the best programmers. I've seen eye-blinkingly bad code. – Maarten Bodewes Dec 31 '20 at 13:02
• Thanks for comment, after your comment I also tried with your idea but still same... – quest Dec 31 '20 at 14:21
• I think "how do I use this program" is not on-topic here. – forest Jan 3 at 6:45

The problem is that some tests require much larger individual bitstreams than is supplied as parameter, and this software is neither written robustly, nor well-tested with small parameters.

In particular, test [09] Overlapping Template Matchings with block length(m) left to the default 9 seems to crash when the tool is passed a parameter less than 1032 or so. That's far less than the 1000000 suggested by the doc.

To run the data.pi file for all tests (which makes sense only as a test of the tool), we can enter

./assess 500000                   (length of the individual bit stream)
0                                 (Input File)
data/data.pi                      (path)
1                                 (all 15 tests)
0                                 (continue with default parameters)
2                                 (2 bitstreams)
0                                 (ASCII)
cat experiments/AlgorithmTesting/finalAnalysisReport.txt


The report contains nothing alarming, as expected.

CAUTION: use of any such statistical test can at best show that a sequence is not random. Passing a test is not a receivable argument that a sequence is indistinguishable from random for one who considers how the sequence is produced.

• Should the format of txt file be exactly same with data.pi or can I use just txt file as a format of 011011 without any space and any newlines? – quest Jan 6 at 11:07
• And so what should be the number of bitstream for appylying all test and what should be the total number of characters in my txt file – quest Jan 6 at 11:12
• @quest: my impression (no insurance) is that newline, perhaps all whitespace, is ignored when using the ASCII format. I suggest using 1000000 bits when running all tests. 250000 is definitely not enough (one of the test fails, though does not core-dump). 500000 at least sometime works. You are on your own. This and all similar tests are pointless except as a quick way to sometime invalidate the hypothesis that a sequence is random. – fgrieu Jan 6 at 13:24

I think that you have to accept Maarten's "eye-blinkingly bad code" comment. Both NIST STS and the NIST 800-90B entropy assessment tools (especially ea_non_iid) have coding errors, spelling mistakes and example sample data that fails it's own tests when they should pass.

igamc is an example of poor/non existent error trapping. It's an arithmetic underflow within an Incomplete gamma function, and classy code would translate it. Unfortunately it's been happening for a long time - NIST randomness test suite returns igamc:UNDERFLOW for most of the tests.

And the reason you're getting it is that you have your option choices backwards...

./asses 24 (because each line have 24 characters in the data.pi except first line).

You also tried ./assess 7467 originally. That's wrong. 24 should be the length of an individual bit stream, in bits (not bytes). The file format is not the bit stream. I can kinda imagine how some of the calculations would go wonky trying to determine randomness of a sample 24 bits long. I did: ./assess 100000. Then select the number of those bit streams you want. I did: How many bitstreams? 10. Please realise that the following formula must hold:

$$\text{bit stream length} \times \text{number of bit streams} \ngtr \text{file size}$$

Look in the data directory for sample files as:-

-rw-rw-r-- 1 ? ? 37500000 Apr 13  2000 BBS.dat
-rw-rw-r-- 1 ? ?  1572864 Mar  2  2000 data.bad_rng
-rw-rw-r-- 1 ? ?  1165666 Mar 25  1998 data.e
-rw-rw-r-- 1 ? ?  1165666 Mar 25  1998 data.pi
-rw-rw-r-- 1 ? ?   125000 Jun 10  1999 data.sha1
-rw-rw-r-- 1 ? ?  1165667 Mar 25  1998 data.sqrt2
-rw-rw-r-- 1 ? ?  1165667 Mar 25  1998 data.sqrt3


You should be able to validate against these. Some are binary, and some are ASCII text. I've just run the test against data.pi and it passed as expected. The file is formatted exactly as:-

   110010010000111111011010
1010001000100001011010001
1000010001101001100010011
0001100110001010001011100
0000011011100000111001101
0001001010010000001001001
1100000100010001010011001
1111001100011101000000001
0000010111011111010100110
0011101100010011100110110
...


Notice the line lengths. And at the end of each line there is a line feed character, ASCII code 0A. Perhaps your lines are too long..?

• Thank you very much! I finally get my account but my other questions are still not merged with account. Once they merged I will accept your answers! Thanks for your all answers – quest Jan 6 at 11:05
• And can you please explain again what is bitstream then? Probably the formay of txt file is not important?? maybe I can use a txt file without anynewlines and any space?? – quest Jan 6 at 11:09
• @quest A bitstream is a series of individual bits in whatever format you dictate to the test. This test seems to prefer bits to bytes. So a ASCII "1" is a single bit (even though it is held in a byte as decimal code 49). ASCII "010"a is 3 bits for this test, even though that is held as 3 bytes in your text file. I hate it. There are several similar questions here about problems with this textiness testing. – Paul Uszak Jan 6 at 12:33
• @quest To wit, is it not possible to gather your samples as pure binary data? You will have quantized them that way (binary). It will have been an additional (in my experience unnecessary) step to encode the samples as ASCII text. – Paul Uszak Jan 6 at 12:34
• so bitstream is that: for instance (just as an example) this is my random number 0101010101 now I have 10 bit right ? and if I say I have 10 bit stream this means that I actually have just single bit as a random number and they are 0 1 0 1 0 1... if I say I have 2 bit stream this means I have two random number and they are 01010 and 010101 IS that correct? And I am sorry but I still didnt' understand what is the problem with ascii and why I cant say ./asses 24 for data.pi. – quest Jan 6 at 12:58