2

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?

user45491
  • 409
  • 2
  • 10
  • 2
    @fgrieu said it first. A statistical test can only fail a CSPRNG, it can never tell us that a CSPRNG is safe. Passing such tests is really easy. CSPRNGs need be more random by many orders of magnitude. They also must not reveal information about their seed, past outputs, future outputs, or internal state even if a hacker can see lots of the RNG's output. – Future Security Nov 14 '18 at 18:06
  • @poncho's answer is correct, but even if you do this test correctly, the rand implementation will still fail miserably: it's similar to the LCG entries at http://www.pcg-random.org/statistical-tests.html#id2 – flaviut Nov 14 '18 at 21:18
  • As an aside from your test results: C's rand() isn't necessarily always the same algorithm, so even if it is found to be cryptographically safe on your current system it might not be on another system your code is later compile on. Never assume something has properties that it doesn't make any claim to have: the standards for rand() make no claim or requirement for the algorithm used to meet any cryptographically relevant standard. – David Spillett Nov 15 '18 at 10:46

2 Answers2

10

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.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • Just a note that the difference between 192-bit and 256-bit is quite huge. So huge, in fact, that 256-bit is physically impossible to crack based on laws of thermodynamics. – Nelson Nov 15 '18 at 05:48
  • @Nelson: I do not know if the reasoning you link to applies when considering the possibility of quantum computers. Because many others do not know, and using 256-bit keys cost so little extra, it's not foolish to use that level. – fgrieu Nov 15 '18 at 07:21
  • 1
    @Nelson: The reservation was specifically about quantum computing. The linked argument hinges on the minimum energy needed for state changes, but the essential feature of quantum computing is that a system can be in a superposition of states, all at the same time. – MSalters Nov 15 '18 at 13:09
10

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...

poncho
  • 147,019
  • 11
  • 229
  • 360
  • Nice answer. 32767 fits into a 16-bit unsigned integer. In my system, that's an unsigned short int. I changed the generator accordingly and it did pass SmallCrush, but it failed PractRand's `[Low1/8]DC6-9x1Bytes-1 ' with just 2^24 bytes. – user45491 Nov 15 '18 at 10:15
  • @user45491: Same thing. USHORT_MAX is at least 65535, not 32767. So the MSB is still non-random in your setup. – MSalters Nov 15 '18 at 13:04
  • @MSalters, yes, I made that mistake: $32677$ is actually $2^{15} - 1$ not $2^{16} - 1$. So now I need to think: I need to hand PractRand only 15 of the 16 bits of a short int. Not sure how to do that at the moment. (Thanks!) – user45491 Nov 15 '18 at 15:42