Hash decrypts key, key decrypts cipher... why?

Question

I noticed recently that a couple of pieces of encryption software (TrueCrypt being one of them) don't directly use a hash of the password as the key for the block cipher. Instead, they generate a random key, use that to encrypt the data, then xor the key with the hash of the password and store the result within the encrypted file's header.

I can see this being useful from the perspective of wanting different keys for different files, even though the password is the same, but I can't think of any other reason. Are hashes weak as block cipher keys, or am I missing something here? Are there any additional security considerations to think about with this kind of mechanism? Also, is this mechanism superior to using keyed HMAC hashes, where the file contains the key?

Answer 1

There are several reasons to use a scheme like this:

• As several other answers have pointed out, it allows changing the password without re-encrypting the entire file.

• Also, it allows re-encrypting the file without changing the password, should this be desired. In particular, a careful implementation can allow incremental re-encryption, so that the file can be accessed while the re-encryption process is running, and so that the re-encryption process can be safely resumed even if the computer crashes while it's running.

• Using an intermediate key also allows multiple passwords to be defined for the same file without having to store all the data twice — just encrypt the same inner key with each password and store them all in the header.

  It's also possible to support other authentication methods besides plain passwords; for example, the inner key could be encrypted with the public half of a public/private key pair (RSA, DSA, etc.), with the private key perhaps in turn stored in an encrypted key file and/or on removable media. You could even have the file accessible both with a password and with a private key file if you like.

  (For technical and performance reasons, you do not want to use public-key crypto algorithms to directly encrypt large files, so in practice, whenever you use such keys for file encryption, this is exactly what you do anyway — encrypt the file with a random symmetric key and then encrypt the random key with the public key.)

• And yes, it also ensures that two identical files encrypted with the same password won't have the same ciphertext. Granted, there are other ways of ensuring this, but it's still a useful side effect.

Answer 2

One reason is that this scheme allows the user password to change without requiring that the encryption key change. To change the user password, merely decrypt the encryption key with the old password and then re-encrypt it with the new password; it's very easy to do. But if the user's password was derived into a key and used to directly encrypt the data, if the user changed their password then the encryption key would also change and all the data would need to be decrypted with the old password and then re-encrypted with the new password. If the user has a lot of encrypted data (say, 500GB), that could take many hours and would be very inconvenient.

And yes, we could use an encryption key derived directly from the user's password. A user's password may be transformed into a key via a cryptographic Key Derivation Function (such as PBKDF2) on the password to output the key. The concept of a KDF is similar to a hash, but it is specifically designed for the purpose of turning a password into a key. Hashes are not designed with this sort of workflow (converting a password into a key) in mind, and in cryptography we dislike using primitives for tasks they were not actually designed for. Hashes will probably do a "pretty good" job of acting like a KDF, but we prefer to use actual KDFs.