Is this test result sufficient to steer clear from this RNG for cryptographic applications?

Question

I'm not really interested in this PRNG. I'm more interested in understanding what it takes to fail the security threshold for cryptographic applications. I'm taking the C PRNG as an example.

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
  unsigned int random;
  srand(1);
  for (;;) {
    random = rand();
    fwrite(&random, sizeof random, 1, stdout);
  }
}

Here's the summary of a small crush by TestU01:

========= Summary results of SmallCrush =========

 Version:          TestU01 1.2.3
 Generator:        crand
 Number of statistics:  15
 Total CPU time:   00:00:21.67
 The following tests gave p-values outside [0.001, 0.9990]:
 (eps  means a value < 1.0e-300):
 (eps1 means a value < 1.0e-15):

       Test                          p-value
 ----------------------------------------------
  1  BirthdaySpacings               1.1e-14
  2  Collision                        eps
  3  Gap                             4.2e-9
  6  MaxOft                           eps
  6  MaxOft AD                      1 - eps1
  7  WeightDistrib                    eps
 10  RandomWalk1 H                    eps
 10  RandomWalk1 M                    eps
 10  RandomWalk1 J                    eps
 10  RandomWalk1 R                    eps
 10  RandomWalk1 C                    eps
 ----------------------------------------------
 All other tests were passed

Is this enough to make me steer clear from C's rand()? What if it had failed only a single test?

fgrieu · Answer 1 · 2018-11-14T23:04:13.853

No test is needed to stay clear from srand for cryptographic purposes, including when a pseudo-random generator is thought. The definition of srand is enough to disqualify it.

That definition states:

void srand(unsigned int seed);

The srand function uses the argument as a seed for a new sequence of pseudo-random numbers to be returned by subsequent calls to rand. If srand is then called with the same seed value, the sequence of pseudo-random numbers shall be repeated.

Problem is: the key is an int, and that's not wide enough. int is typically 32-bit, sometime 16-bit, rarely more than 64-bit, and 80-bit is a bare minimum for a modern key (we want more like 128-bit, or 192-bit when considering multi-target attacks, or 256-bit for extra peace of mind when considering the possibility of quantum computers).

Poncho beats me at first stating that the test is misapplied, since the output is not supposed to consist of uniformly random bits, which likely SmallCrush expects. Problem is,

The rand function computes a sequence of pseudo-random integers in the range 0 to RAND_MAX.

The value of the RAND_MAX macro shall be at least 32767.

and RAND_MAX is often INT_MAX. It's then likely that for sizeof(int) bytes written, one byte has its high-order bit stuck to 0, which should be caught by many statistical tests.

CSPRNGs can not be validated by statistical tests. Failure of such test only indicates (with high certainty) that the PRNG or/and test procedure is flawed (here, both are). Success does not prove anything, and indicates very little. Image: it's like validating a road bridge by having an ant cross it, when the actual things to test are high load, wind-induced oscillations and long-term corrosion of metal parts.

Also, many cryptographic applications need a True RNG (with output unpredictable from the code). That's not even touched by either srand or the test.

score 10 · Accepted Answer · answered Nov 14 '18 at 14:02

Actually, this case is a misapplied test. rand() is defined to generate numbers between 0 and RAND_MAX, which is a compiler-defined constant which is positive as an int. That means that the range of possible results $[0..RAND\_MAX]$ is strictly smaller than the range of results you are writing $[0..UINT\_MAX]$. For example, if you are on a machine with 32 bit int's, then the msbit for every value you write will always be 0, that is, every 32nd bit will always be zero.

Of course the statistical tests will throw up their hands at that; obviously, real random outputs won't do that. However, that's not the fault of rand(), instead, it is the fault of how you're using it.

Now, to address your question:

I'm more interested in understanding what it takes to fail the security threshold for cryptographic applications

Statistical tests don't tell you much; hard failures are an indication that something may be up (or you're misapplying the test, as is the case here); however:

Any such PRNG would need a good entropy source; rand() only allows srand(), which allows a single (unsigned int) as input; that's not sufficient
Any such PRNG should be designed and analyzed as giving an indistinguishable output; rand() implementations rarely are...

Is this test result sufficient to steer clear from this RNG for cryptographic applications?

2 Answers2