in reply to Re^6: A better rand() for Win32
in thread A better rand() for Win32

I am back as the author of this posting. Finally to respond !! The "cryptographic" is important form the standpoint of some games like computer backgammon that use some neural net learning algorithm. The game algorithm may be hacking the Pseudo Random Number generator's algorithm rather than game strategy itself or a combination of both. So by randomizing the seed (gathering entropy ) from Current Time, process ID, Memory info, and so on, (As described about for CryptGenRandom() API that CAPICOM uses) a human or machine has a harder time figuring out what LCRNG you are using. Remember, a random number generator is no longer random if its seed and algorithm are known. The srand documentation shows a simple unix entropy example: srand(time ^ $$ ^ unpack "%32L*", `ps auxw | gzip`); You want to seed your generator with as much entropy or in plain English "garbage" or "noise" bits. Having said that, Intel has a hardware resistor noise intereface to further add to the entropy pool. I am not sure how to use that in CAPICOM. The Intel site doesn't seem to indicate that Windows XP is supported.

Replies are listed 'Best First'.
Re^8: A better rand() for Win32
by syphilis (Archbishop) on Aug 02, 2007 at 07:03 UTC
    a random number generator is no longer random if its seed and algorithm are known

    There are a numer of Cryptographically Secure Pseudo Random Bit Generators for which that statement is not true (for some definition of "seed", anyway). I'm thinking of the RSA, Blum-Blum-Shub and Micali-Schnorr pseudorandom bit generators - the only CSPRBG's with which I'm in any way familiar.

    The cryptographic strength of these generators relies on the indeterminability of the 2 chosen (large) primes upon which they are based. Knowing both the algorithm and the seed value that was used is of no help if the 2 primes are not known. Of course, it could be argued that those 2 primes are, in effect, part of the "seed" ...

    The nice thing about these CSPRBG's is that they can be used to provide "quality" pseudorandom numbers without any need to "gather entropy" at all. (For cryptographic purposes, however, you'd be well advised to gather plenty of entropy when it comes to choosing the 2 primes.)

    Cheers,
    Rob
      Thanks , for making a finer point syphilis , looks like this discussion is getting into the more advanced aspects of Crypto/RNG.
      I should add from my last entry, GetRandom() calls CryptAcquireContext to use another phase of randomizing - hashing (using PROV_RSA_FULL by default) then calls CryptGenRandom.