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 < 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: