Of course you can use CryptGenRandom, but only if you don't need to generate a sequence from a seed.
Of course you can use CryptGenRandom, but only if you don't need to generate a sequence from a seed.
So, drew99, have you gotten any further?
My post #4 is an implementation of the Blum-Blum-Shub algorithm, and while its primitive operations are inefficient, it works quite reliably.
If you can, I'd recommend using the GNU multiple precision arithmetic library for the primitive operations. You could have a generator constructor, which takes a modulus (pq = m) and the initial state/seed (x) as binary data, returning a dynamically allocated opaque binary blob (containing the generator state and specs). A function would take that pointer, generate the next x, and return say the low 32 bits of x. That should not need a lot of code to implement, and is a true Blum-Blum-Shub implementation.
Or, if you cannot use the GNU MP library, then you can do the very same using my code, too. Just remember that it was intended as a conversation/learning piece, not for end use.
Last edited by Nominal Animal; 10-24-2012 at 07:51 AM.
For cryptography, that is a feature. You don't want to make the random number sequence repeatable from a seed (AFAIK, all PRNGs use a seed of some kind, including cryptographically-secure PRNGs, but those typically use a very large seed of hundreds or thousands of bits).Originally Posted by drew99
In my opinion, the goal is to make not predictable/calculable a number of the sequence knowing the previous number, not to make unique sequence, unless you are designing a system wth asymmetric key. What applications can you see in a completely unique random sequence? The only possibility would be to include the encrypted key in the output, but it is not safe.
