I don't know the specification of SHA-256 or SHA-512, but their output hashes are totally different for the same input. To protect from GPU cloud hashing attacks on password hashes you would use a PBKDF with a lot of iterations. Some GPU's can produce SHA-256 hashes really fast, particularly AMD GPU's, as explained below https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU#Why_are_AMD_GPUs_faster_than_Nvidia_GPUs.3F so yeah GPU's are currently more specialized for SHA-256 than SHA-512. However, by using a PBKDF you can strengthen your password by much more than you can by switching from SHA-256 to SHA-512. PBKDF will use SHA-256 (or whatever) and iterate perhaps a hundred thousand times. So if using SHA-512 takes twice as much time for the GPU to make a hash, using SHA-256 with PBKDF with 100,000 iterations will take 100,000 times as long. Of course you could switch to SHA-512 with so many iterations, but you can always just add more to SHA-256 as well. There is no problem to make key generation from a password take X amount of time with Y hardware, and it is just as effective to use a PBKDF with more iterations as it is to switch to a new hashing algorithm. I don't think even GPU's have this problem theoretically, they are just not as optimized for SHA-512 as they are for SHA-256. Although it is probable that SHA-512 takes longer than SHA-256 inherently anyway, but as I said before you can use a PBKDF to make key generation take as long as you want on any given hardware. What are they using them for though, is the important question. Also, how are they using them. It is literally impossible to use a 512 bit output for an AES-256 key, AES-256 needs a key that is exactly 256 bits. The only way you could use a SHA-512 hash for AES-256 is if you only use half of the output bits. In which case I would probably just use SHA-256, since it matches up. If I was using a password based key and wanted to make an attacker spend more time to guess passwords, I would use SHA-256 with a PBKDF with as many iterations as the user could stand. I am not positive if the entropy distribution problem actually will come into play, but from what I have read on hash functions I would be afraid that it would. A cryptographer friend said he would argue that both methods are equally as secure. I noted that he didn't say they are equally secure. I would therefore lean toward caution by using SHA-256 to key a 256 bit encryption algorithm, rather than using half the output bits of SHA-512. Truecrypt uses those hash functions as part of its custom PRNG, it doesn't directly use them to produce keys. Truecrypt produces keying material with its PRNG, the hash functions it uses as entropy distributors (entropy diffusers they call them). http://www.truecrypt.org/docs/random-number-generator I can't really comment on the way their PRNG works. I would have done it a little bit differently, and more straight forward imo. After getting the raw input from mouse position etc, I would concatenate it together into a single buffer every few seconds, then take the SHA-256 sum. Then I would take this SHA-256 sum and use it as the basis for the next round, with new raw input being concatenated to the previous SHA-256 sum, and then after a few seconds the new value being hashed, etc, for however long the user desires. Another property of a cryptographic hashing algorithm is that the output hash should contain exactly as much entropy as the input fed to it. So if I feed SHA-256 1000 bits that contain 1 bit of entropy, the output SHA-256 hash should have 1 bit of entropy. If I use this hash for the basis of the next output, and concatenate 1000 bits with 1 bit of randomness to it, when I hash this the next SHA-256 output should have 2 bits of entropy. At this rate, it will take 256 cycles to have 256 random bits. Then I would key AES-256 directly with this hash value. Of course the hash value used to key AES-256 is not based on a password. Truecrypt generates a random key for AES-256 and then it encrypts this key with another key generated by the users password. I wouldn't use SHA-512 because I would be too worried that the user would only accumulate 256 bits of entropy, and that they would be distributed evenly thoughout the 512 bit output, leading to the AES key only having 128 bits of entropy. Though I suppose you could use SHA-512 and XOR every pair of bits together to get a 256 bit key. Or you could take the SHA-256 value of the SHA-512 value. Using half of the SHA-512 value seems risky though. And I don't see a reason to use SHA-512 and then SHA-256 versus just using SHA-256 to begin with.