MSC32-C. Properly seed pseudorandom number generators

MSC30-C addresses the problem that numbers generated by rand() have a comparatively short cycle, meaning that the numbers may be predictable. Suppose we have the following code:

for(int i=0; i<RAND_MAX; i++){
   printf("%d, ", rand());
}

After some iterations (I believe at about RAND_MAX/2 - according to birthday paradox), we will start having collisions. Right?
 
MSC18-C is quite different from MSC30-C in the following sense:
MSC30-C: Calling rand() in a large for loop will sooner or later result in generating the same random numbers.

MSC18-C: Calling rand() to create a sequence of random numbers will always result in the same sequence generated at different runs of the program. For example, suppose we want to create a sequence of 10 random numbers and thus we write the following code:

for(int i=0; i<10; i++){
   printf("%d, ", rand());
}

Running our program will produce let's say: 41, 18467, 6334, 265000, 19169, 15724, 11478, 29358, 26962, 24464 (actually this is a real sequence generated when I run the program)

Running the same program a second time will produce the exact same sequence. More generally, any subsequent runs of the program will generate the same sequence.

If program changes to:

srand(time(NULL));

for(int i=0; i<10; i++){

   printf("%d, ", rand());

}

then different runs of the program will produce different sequences of random numbers.

The same thing holds for random() for POSIX, too! And the solution is also the same. Use of srandom() seeds random() to produce different sequences at different runs of the program. I have not written this yet, but I will do so soon. Again:

MSC30-C: Mentions that random() generates random numbers generated with a bigger cycle.

MSC18-C: Mentions that when come to sequences of random numbers generated in different runs of the program, then random() has the same behavior with rand() and should be properly seeded.

I will also check CryptGenRandom() for Windows.

From a security perspective,  MSC18-C is different in the following sense:

MSC30-C: A malicious user should have to wait a quite reasonably amount of time before starting predicting (with some probability) patterns of generated random numbers.

MSC18-C: After the first run of the program, a malicious user will know the sequence of random numbers to be generated in any subsequent runs.

If our program is a game where the player has to find hidden treasures, then the next time a  user plays, (s)he will know where the treasures are and (s)he can cheat!

In a worse case, suppose that Alice and Bob want to communicate 10 times per day. Suppose also, that they use asymmetric cryptography (Diffie-Hellman, or El-Gamal, or any other protocol where parties pick some random numbers). Suppose Bob and Alice run a program to generate a sequence of 10 random numbers. Each number produced will be used in the corresponding communication in between them, i.e. 1st number will be used for their first communication and then dropped, 2nd number for their second communication and then dropped, etc. The problem is that if Bob and Alice run the same program the next day to produce another sequence of random numbers, then the sequence generated will be the same! On the other hand, if Alice and Bob use srand() to seed rand(), then different sequences will be produced.

Both MSC30-C and MSC18-C refere to the problem of randomness, but from a different point of view and by transferring the time window until collision takes place. Vulnerable time window for MSC18-C will be just the next run!!!

Taking all the above into account, I am starting thinking if this should be a rule instead of just a recommendation. What do you think about it?

It was not my intention to advocate proper usage for deprecated rand(). My objective was to address the problem of generating different sequences of random numbers. The same problem holds for rand(), random() and I believe this will also be the case for CryptGenRandom(). I will check and update MSC18-C soon.

I also think that MSC18-C should be changed in something like "ensure your random number generator is properly seeded". Shall I do this?

I would also like to ask how the  Risk Assessment table is going to be filled. In adition, what about Automated Detection and Related Vulnerabilities? Any hints?

I'm not sure if seeding a RNG with the current time is theoretically vulnerable to an attacker modifying the time, since, due to the interval between time modification and RNG seeding, an attacker can't use time modification to pass a known value to a RNG seed.

Still, if one is that concerned about randomization, one would not be using rand()/srand().

Other points:

• The rule and code examples still use rand()...use something else like random() in the code examples.

• Mention MSC30-C, which explains why we can't use rand() securely.

I have completed the rule. The rule does address the seeding for all three functions, i.e. rand(), random() and CryptGenRandom(), mentioned in MSC30-C. Do not use the rand() function for generating pseudorandom numbers for completeness. I have the feeling that as the rule is written now, it both examines the case for seeding rand() and does not contradict to MSC30-C.

Please take a look and let me know if further modifications are needed.

So, do you think it is better to change the comment in the first compliant solution to something like /*  Create seed based on current time */? I can do this but I don't get it. OK, ISO C defines time_t as an arithmetic type, but does not specify any particular type, range, resolution or encoding for it. But if you run time(NULL) and convert the result to years and days, then you will find 'today' counted from 'Unix Epoch'. Do you think that a different C compiler would give another result?

Your results are probably funny because in POSIX the value returned by time(2) represents the number of seconds since the epoch. So calling time(2) twice during the same second returns the same result...consequently your seeds are the same and you'll therefore get the same random sequence in each loop iteration. As noted in previous comments, C99 only requires that time(2) return an integral type representing time, and it is POSIX that requires time(2)'s return value to be expressed in seconds.

BTW my srand48(3) manpage says:

NOTES
These functions are declared obsolete by SVID 3, which states that rand(3) should be used
instead.

Fixed, thanks.

Ryan Steele has provided us with a new compliant example using BCryptGenRandom().