For my next project, I need a 16-byte random pool, what's the best to use?
1) CryptGenRandom
2) SHA-256 of first plaintext block
3) PRNG using AES/SHA (worst-case scenario= own implementation)

[edit] It's an Initialization Vector for AES-256, 128-bit block size.

Since you want random bytes number 2 is not valid.

number 3 still needs a seed of random input.

That leaves number 1.

Although it depends on the quality of randomness you require. For example, is it for high security stuff or maybe just some fancy game effect? For simple requirements use number 1, for good security requirements use number 1 and other random sources all combined.

I'm using it to generate a 16-byte initialization vector for my new project, a library with implements 5 modes of encryption operations. Most need an IV, and I read in FIPS modes of operation publishing that "The IV can be random or unique to the message", in different words, but it says "UNIQUE".

That's where I thought of using SHA-256 hash of the message (sorry, full message), and xor'ing the two 128-bit parts of the hash together to produce 16 bytes for the IV.

The TrueCrypt software uses repeated CryptGenRandom calls, hashing, and mouse-movement inside of the window to generate it's random pool.

I do not think that I should need much more than CryptGenRandom for an IV, but I'll be glad to combine it with a PRNG seeded with a user-supplied value (maybe the result from CryptGenRandom?) and hashing combined.

If anyone can show me how to code a Windows program I would be so thankful, but I will probably be referred to the tutorials. All it would be is a window with a message across it, and tracks mouse movements repeatedly until user presses a button. (GetCursorPos I have seen).

If you want random numbers for crypto purposes you CAN'T use the message hash. This is because the message can be manipulated and duplicate messages will give the same IV and leak some information.

CryptGenRandom is just a PRNG seeded from some system tables and process tables etc. It is quite a good source of randomness but you should still consider enhancing it with other non-predicable sources like the TSC, keystroke timing and mouse position/timing.

use Windows Cryptographic API... it takes data from sound card buzz etc...

Thanks a lot for the advice, I've considered everything (yes, I did realize I shouldn't use a hash of data, but I read "unique" and it did imply that).

Here's the process I've thought of (overkill, but that's what I want ).

1) Pool 1 = CryptGenRandom [16]
2) Pool 2 = CryptGenRandom [32]
3) Pool 3 = SHA-256 (rdtsc)
4) Pool 4 = SHA-256 (Pool 2)
5) Pool 5 = Pool 3 xor Pool 4
6) Pool 6 = < first 128 bits of pool 5 xor'd the second 128 bits >
7) Pool 7 = AES-256 ( data = Pool 6, key = Pool 2)
Final = Pool 1 xor Pool 7

Note, by "Pool" I mean a subsequent operation, not necessarily actual memory.

You can't increase the randomness by hashing anything. Steps three through seven are unnecessary. Use the TSC directly and simply xor it it into the pool.

Just get all your sources of randomness and xor them together, then do a final hash and use the output.

But note above your total sources of randomness is only two, CryptGenRandom and TSC. And the TSC can only give you a few bit of entropy at best.

So by "using the TSC directly and xor'ing into pool", I should:
1) CryptGenRandom [16]
2) Rdtsc [8]
3) Xor Rdtsc twice into cryptgenrandom pool
4) Hash this, compress the hash by xor'ing halves together

And I get 16 bytes. I'll go with your idea, but I've read of using AES-256 to encrypt the pool as a final step, I think I'll add that in also for something to do. (use another CryptGenRandom as the key).

Alexp:
there are not only wor instruction.
not, neg, ror, rol, xlat, xchg ...

You won't achieve anything by doing xor twice.

If you want 16 bytes of random data just get 16 bytes from CryptGenRandom, xor in any other sources of random data ONCE each - then, to cryptographically secure it, hash it and take the first 16 bytes of output. You can't improve the randomness by doing all the 'two halves' things or 'xor twice' things.

edfed: Yeah, but I like to stick with xor for now, I still have no experience with RNG's

revolution: By xor'ing TSC twice I meant that the TSC is only 8 bytes, and the pool is 16 bytes, so I would like to combine it with all 16 bytes of the random pool. WIth the SHA hash, I wasn't sure if only taking the first bytes would hurt security, I was thinking about a way to combine all of the hash into one value. Thanks!

I know what you were thinking, but it won't help and it can hurt. I don't recommend you do it twice.

is it for time or randomness critical operations?

? ?

is it for time critical operations?
-->"it shall generate prng very fast".

or random critical operations?
-->"it shall generate the numbers the more random as possible".

I think that speed is not an issue since the OP initially wanted to do all sorts of transformations. For speed one would simply use an LCG or MT.

Speed is not an issue, and so here is my plan:

1) CryptGenRandom [16]
2) Rdtsc[8] xor CryptGenRandom[bytes 1 - 8]
3) SHA-256 this pool, and use first 16 bytes as random pool.

Don't you want to use a few more sources of randomness?

GetTickCount
GetSystemTimeAsFileTime
GlobalMemoryStatus
GetDiskFreeSpaceEx

Some of these only give one or two bits of effective randomness but it all helps and it doesn't do any harm to xor in a few things here and there.

Well, I'll get it working for now. It'll take a few days of planning to figure out how I'm going to coordinate all 5 modes of encryption, not even counting the AES routines themselves (and keying, ect..) all into one library. I'll figure out how everything will work together today, maybe even make a code template for later.

i don't know about you but i created a random number generator it generates 32 bit signed numbers. i created it just for cases where a lot of random numbers needed to be generated with little impact on the system. i tested this in my old althon xp and it ran at close about 1/3 the speed of a typical linear random algorithm. it uses the Mersenne Twister Random algorthim.