Actually it looks like Truecrypt is using a similar system (I just read the entire thing, before I only glanced at it), but I don't know why they have made it so much more complicated. So essentially Truecrypt is describing the buffer from the scheme I mentioned, where raw input data is added (from mouse position, etc). Truecrypt diverges here, after they fill the buffer up they don't ever replace it but rather they modify it. When new input comes in after the buffer is filled, they change the value of the current position in the pool to be the current position in the pool modulo 28 the new raw input. Now Truecrypt divides the buffer into sections that are the size of the output of the hash function selected by the user. Truecrypt goes through each section and generates a value that is equal to the hash value of every section in the buffer, and then uses modular exponentiation to transform the current section to the current section ^ value generated by the hash function. It does this for every section in the randomness pool. Truecrypt then uses this randomness pool to generate keying material, first going through some steps to transform it a final time. I think that this is kind of an over complicated method personally. I would do something more like this: Have the buffer that raw input is added to, every period of time (or better yet every time the buffer is filled), I would take the SHA-256 value of the buffer. Then I would totally clear the buffer, and add the SHA-256 value to it. Then as more input comes, I would add it to the buffer past the SHA-256 value, and when the buffer is filled again I would take the SHA-256 value of it again. I would do this for some number of rounds, or as long as the user desires. At the end, I would take a final SHA-256 value of the buffer. If I was only generating an AES-256 key, I would use the final SHA-256 hash for the key. However, Truecrypt is using their PRNG to generate more than the key, so I would need more than 256 bits. In this case, I would do the following: Using the final SHA-256 output as a seed, I would then hash it out once more. If S is the original value and O1 is the hash of the original value Ox = H(S || Ox-1) O1..Oz would be my pseudorandom material to use for keying and other operations, where Oz is the final Ox. The original seed is generated securely because: A. Cryptographic hash functions preserve entropy, meaning the output of H(X) contains as much entropy as X. Therefore, with R = raw input H(R1) = A H(A || R2) = B H(B || R3) = D D must contain as much entropy as the total entropy of R1, R2, and R3 combined. B. Cryptographic hash functions distill entropy If H produces 256 bits of output, feeding H(1000 non-random-input-bits + 1 random-input-bit) = 256 bit output with 1 random bit (due to preservation of entropy there is 1 bit of entropy in the output, distilled from 1001 bits to 256 bits) C. Cryptographic hash functions distribute entropy If H produces 256 bits of output, H(1 bit of entropy) = 256 bits each with 1/256 bits of entropy therefore if there are 256 bits of entropy total fed to H during the seed generation process, the final value will be 256 random bits. The final output material is secure because: A. The seed is used to generate every 32 bytes of output Ox = H(S || Ox-1) Without knowing the seed value an attacker cannot use Ox to determine Ox-1 or Ox+1, because a cryptographic hash algorithm is (ideally) a one way function. H(S) = O1 (the attacker can not determine the seed from the first output because doing so would mean H is not a one way function) H(S || O1) = O2 (Same as above, plus the attacker can not guess O2 with knowledge of O1 unless they also have knowledge of S, and S is 256 bits of randomness) H(S || O2) = O3 etc. It should be safe to use randomly sized sections of output as well, since the entropy is evenly distributed by the hash function. That means just because the hash outputs A9 and A is used for the publicly viewable salt and 9 is used for the secret key, the attacker should not be able to use knowledge of A to be able to determine that the key starts with 9, since the entropy of A is the same as the entropy of 9 and the two are probabilistically independent of each other.