looks like Truecrypt uses the same hash functions for their PBKDF as well I would be hesitant to go that route personally because of concerns due to entropy diffusion (I used to say distribution but seems everybody calls it diffusion so time to switch my terminology. Diffusion = the input entropy is evenly distributed throughout the output) from the hash function. Some links and short quotes from them www.iacr.org/archive/crypto2004/31520493/clean.pdf Actually had some trouble digging up citations for these properties, I wish I could find the first thing I read when I first learned about cryptographic hash functions, it defined all of these properties. But hopefully these two quotes are enough to show my concern: the hash function distills randomness up to the maximum size of the output of the hash function, and it takes the possibly non-uniform randomness of the input and produces a uniformly random output. My concern about using SHA512 to produce a key for a 256 bit symmetric algorithm is that if only half of the output of SHA512 is used, perhaps only half of the randomness of the password is used, if the password contains less than 512 bits of entropy. PBKDF2 doesn't XOR together bit pairs of the output, or take the SHA256 value of the output. It keeps running SHA512. So they really are keying AES-256 with partial output from SHA-512. I would love for someone to explain to me why entropy diffusion after hashing a password with less than 512 bits of entropy doesn't lead to a weakened key when half of the 512 output bits from the hash are used. I did ask about this in the past and someone said he would argue that using part of a SHA512 hash like this would be just as safe as using SHA256, but he didn't explain why or seem 100% certain. I would imagine it is safe or else there would be warnings about it with PBKDF2 or something I imagine, but to me it doesn't make sense. If hashing an input uniformly distributes its entropy into the output, and the input has 256 bits of entropy, and the output has 512 bits, it seems that each bit of output has half a bit of entropy, and therefor taking 256 bits from this output to key AES-256 would have 128 bits of entropy only. Again, love for someone to explain to me why I am wrong (I wouldn't be surprised if I am, but I just don't see why), or explain to me why it is better to use half of a SHA512 hash versus just using a secure hash that produces the number of bits needed to key the symmetric algorithm in the first place. In the case of using a hash function that produces less than 256 output bits I wouldn't see this concern, because the PBKDF can stretch the randomness of the password into an arbitrary length stream, but when using a hash function with more than 256 output bits it seems that although it can stretch the randomness of the password into pseudorandomness still, the entropy will still be diffused throughout the output bits (meaning with 256 bits of randomness in the password, you still have 256 bits of entropy in an arbitrary number of 512 bit outputs, but each of the output bits only has half a bit of entropy), which would seemingly cut the effective entropy of the password in half if it isn't enough to fill the limit of the hash function used (because 256 bits spread over 512 bits of output means each bit has half a bit of entropy, and when you use half of the final output to key the 256 bit algorithm, it means your key only has 128 bits of entropy. Or if your password has only 30 bits of entropy, the key has only 15 bits of entropy, since 30 bits of entropy diffused over 512 bits means each output bit has .05859375 bits of entropy, and .05859375 * 256 used bits = 15 bits of entropy). However even in the case of using a hash function with 160 bits of randomness, it seems that the limit of the security would be 160 bits. You can stretch a 160 bit seed out to an arbitrary length stream, but cracking the initial seed will always allow you to generate the entire stream. This is easy to prove, assume you have a single random bit, it is either 1 or 0. You can stretch this out indefinitely by hashing it with a counter for example, so: H({1,0}) = O H(O || 1) = O1 H(O1 || 2) = O2 but this only has 1 bit of security, because the attacker knows you either started with 1 or with 0. So I think you can stretch the initial entropic seed out indefinitely, but the total security of the system cannot be larger than the initial seed. So using a 160 bit hash function for the PBKDF to key a 256 bit algorithm means you cannot have more than 160 bit security. So I am not sure how I feel about ANY of the hash functions that Truecrypt offers! Either we can use a 512 bit hash algorithm and diffusion of entropy will cut the effective keyspace of most passwords in half (it seems to me, please tell me why I am wrong), or we can use a 160 bit hash and the security of AES-256 is actually limited to 160 bits, since passwords with more than 160 bits of entropy don't contribute additional entropy to the PBKDF output . Why don't they include a 256 bit hashing algorithm??