Random Number Generator based on AES CTR I've just about done tinkering with an open source DRBG, and I sure would appreciate a bit of advice from this community. Here's the link to the project, hosted at codeproject.com. 

It is written in C#, the code is clean and well commented.

The design criteria:


The same seed must generate the same random output each time.
It must be fast.
It must be extremely difficult to unwind.
It must produce excellent random output.


In its simplest form, it is an AES CTR using block chaining. To address criteria #3, I have added methods that reset the state of the key/iv/counter by whitening them and then using the SHA256 hash value.
An example of 'whitening' the data:

private byte[] ExtractArray32(byte[] SubBuffer)
{
    UInt32[] tmpNum = new UInt32[8];
    UInt32[] arrNum = new UInt32[16];
    byte[] data = new byte[64];
    Int32 ct = 0;
    // copy first array in
    Buffer.BlockCopy(SubBuffer, 0, tmpNum, 0, 32);
    // get the first buffer table index
    UInt16 iter = ExtractShort(tmpNum[0], 10);

    // randomize the bits
    for (int i = 0; i &lt; 8; i++)
    {
        arrNum[ct++] = ~tmpNum[i] ^ SEED1024[iter];
        iter = ExtractShort(arrNum[ct - 1], 10);
        arrNum[ct++] = tmpNum[i] ^ SEED1024[iter];
        iter = ExtractShort(arrNum[ct - 1], 10);
    }

    // copy it to byte array
    Buffer.BlockCopy(arrNum, 0, data, 0, 64);
    // get the hash
    return ComputeHash64(data);
}


I know some people don't like it when someone posts code here, but it makes it so much easier to explain with a visual representation…

So what's happening here, is a 32 byte value, say the original key, is copied to a uint32 array (8 * 4 bytes), then copied into a new uint32 array (16 * 4 bytes), on the first interval, the value is reversed, on both, the value is XORed with a uint32 from a 1024 * uint32 table of random values. The table index is the last 10 bits of the previous value (0-1023). This is how I whiten and expand the array so that it aligns with the 64 byte block size of SHA256. The return is the hash value, which becomes the new value.

Questions:


Is this a good way to whiten the data? Is there a better way?

I do realize that flipping a single bit will give me a completely different hash value, but this goes towards criteria #3, make it difficult to unwind.

There are 4 different prototypes, their primary difference being how and when a state reset occurs; one is configurable via a property (10Kib default), another resets after every 4 block transforms (64 bytes), another resets at random. 
Is there an ideal interval at which an AES CTR generator should be reseeded? Is reseeding too often introducing patterns that might be exposed by some form of differential analysis?

I think the best way to get a handle on what I've done, is to just check out the article, nothing too complex, but it really could do with some scrutiny before people start using it in the wild, which leads me to my last question..
How can this be made stronger? How would you improve upon this? ..and are there any serious flaws in the implementation?

I think the most important criteria is that, should an attacker get a portion of the random output, say message data from an xor cipher, it must be as difficult as possible for the attacker to unwind it back to the initial state, given that any changes do not seriously impede upon the other criteria..


Here's the new algorithm:
First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments.

Now, some observations. I haven't read all your code, so I may misunderstand things.



  Is this a good way to whiten the data? Is there a better way?


Looks unnecessarily complex. AES output is already white, unless AES is broken, so you shouldn't need to do any whitening on the output. The massive table which you use for stretching doesn't seem very secure. For example, you are using secret array indices, which may allow for timing attacks.

  Is there an ideal interval at which an AES CTR generator should be reseeded?


A normal AES generator should be reseeded after $2^{48}$ blocks of output at the latest, according to NIST. That number prevents the attacker from having more than a $2^{-32}$ probability of an advantage.


  Is reseeding too often introducing patterns that might be exposed by some form of differential analysis?


If you have a good source of numbers to feed it, you can do it often, but then why not use those numbers directly? (Performance, maybe, in which case you want relatively infrequent reseeding, but much more often than required is possible.)

Seeding with bad input should only hurt if you use an update system that overwrites previous state and can lead to identical key &amp; IV.

  How can this be made stronger? How would you improve upon this? ..and are there any serious flaws in the implementation? 


I would rip out the whitening stage, for the reasons I mention above, and use AES output as the random output. If you want frequent reseeds and don't have access to a fast TRNG, you could leave an SHA-256 loop for updating the AES key.

Alternatively, if security is the objective, decouple the hash based RNG from AES and run them independently, e.g. XORing the outputs.

A couple more things that seem unnecessary: you are XORing two halves of an SHA-256 output together – using one would be as strong unless SHA-256 is broken; you are XORing the AES counter into the IV, when I think you would be better off treating it as a single counter with a longer period.