Is this test result sufficient to steer clear from this RNG for cryptographic applications? 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 &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

int main(void)
{
  unsigned int random;
  srand(1);
  for (;;) {
    random = rand();
    fwrite(&amp;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 &lt; 1.0e-300):
 (eps1 means a value &lt; 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?
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.