...
Rule MSC30-C. Do not use the rand() function for generating pseudorandom numbers addresses RNGs from a different perspective, i.e. the time till first collision occurs. In other words, during a single run of an RNG, the time interval after which, the RNG generates the same random numbers. The rule MSC30-C deprecates the rand() function as it generates numbers which have a comparatively short cycle. The same rule proposes the use of random() function for POSIX and CryptGenRandom() function for Windows.
The current rule (MSC32-C) examines these three RNGs in terms of seeding. Noncompliant code examples correspond to the use of an RNG without a seed, while compliant solutions correspond to the same RNG being properly seeded. Rule MSC32-C addresses all three RNGs mentioned in rule MSC30-C for completeness. Rule MSC32-C complies to MSC30-C and does not recommend the use of the rand() function. Nevertheless, if it is unavoidable to use rand(), at least, it should be properly seeded.
...
This noncompliant code example generates a sequence of 10 pseudorandom numbers using the random() function. When random()}} is not seeded, it behaves like {{rand(), thus produces the same sequence of random numbers at different calls.
...
| Wiki Markup |
|---|
[CryptGenRandom()|http://msdn.microsoft.com/en-us/library/aa379942.aspx] does not run the risk of not being properly seeded. The reason for that is that its arguments serve as seeders. From the Microsoft Developer Network {{CryptGenRandom()}} reference \[MSDN\]: |
| Wiki Markup |
|---|
:If an application has access to a good random source, it can fill the {{pbBuffer}} buffer with some random data before calling {{CryptGenRandom()}}. The CSP \[cryptographic service provider\] then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the {{pbBuffer}} buffer before calling {{CryptGenRandom()}}.\\ |
...
The CryptGenRandom function fills a buffer with cryptographically random bytes.
Syntax
BOOL WINAPI CryptGenRandom(
__in HCRYPTPROV hProv,
__in DWORD dwLen,
__inout BYTE *pbBuffer
);Parameters
Wiki Markup hProv \[in\] Handle of acryptographic service provider(CSP) created by a call toCryptAcquireContext. dwLen \[in\] Number of bytes of random data to be generated. pbBuffer \[in, out\] Buffer to receive the returned data. This buffer must be at leastdwLenbytes in length. Optionally, the application can fill this buffer with data to use as an auxiliary random seed.
...
\\
| Code Block | ||
|---|---|---|
| ||
HCRYPTPROV hCryptProv;
union /* union stores the random number generated by CryptGenRandom() */
{
BYTE bs[sizeof(long int)];
long int li;
} rand_buf;
if(CryptAcquireContext(&hCryptProv, NULL, NULL, PROV_RSA_FULL, 0)) /* An example of instantiating the CSP */
{
printf("CryptAcquireContext succeeded.\n");
}
else
{
printf("Error during CryptAcquireContext!\n");
}
for(int i=0;i<10;i++)
{
if (!CryptGenRandom(hCryptProv, sizeof(rand_buf), (BYTE*) &rand_buf))
{
printf("Error\n");
}
else
{
printf("%ld, ", rand_buf.li);
}
}
output:
1st run: -1597837311, 906130682, -1308031886, 1048837407, -931041900, -658114613, -1709220953, -1019697289, 1802206541, 406505841,
2nd run: 885904119, -687379556, -1782296854, 1443701916, -624291047, 2049692692, -990451563, -142307804, 1257079211, 897185104,
3rd run: 190598304, -1537409464, 1594174739, -424401916, -1975153474, 826912927, 1705549595, -1515331215, 474951399, 1982500583,
...
|
...