Encryption and HMAC with the same password

Question

I need to send authenticated ciphered messages by using a single password. Reusing the same (derived) key for the block cipher and the HMAC is not a good practice, I know.

My initial idea is to derive two different keys from the password in order to apply a encrypt-then-MAC scheme:

Key1 = PBKDF2(passwd, SALT1, ITERATIONS1)

Key2 = PBKDF2(passwd, SALT2, ITERATIONS2)

Let M be the plaintext, the message sent is:

AES-CTR_Key1(M) || HMAC-SHA256_Key2(AES-CTR_Key1(M))

SALT1, SALT2, ITERATIONS1, ITERATIONS2, and the IV (counter) are also attached.

Do you find any vulnerability in this scheme?

It looks good to me, but I’d like to know your opinion.

I know that AES in CCM mode (counter with CBC-MAC) is an alternative.

Answer 1

Here are some weaknesses (the first one is the most serious):

• If you do not include the encryption IV in the input to HMAC, then attackers could modify the IV and induce a corresponding change in the message without being detected. Similarly, the attacker could modify SALT1 or ITERATIONS1; the HMAC would still match, but you would get junk upon decryption. For encrypt-then-MAC, you MUST compute the MAC over everything that contributes to the decryption. In your description, the HMAC input should be an encoding of a structure containing the encrypted data itself, but also the IV, SALT1, ITERATIONS1, and any symbolic identifier for the used algorithms (in case you want to make some provisions for algorithm agility).

• PBKDF2 is a password hashing function. It is made slow with a lot of iterations. Since slowness impacts attacker and defender alike, you cannot set the iteration count arbitrarily high. In your description, the defender must use two PBKDF2 invocations in normal usage, thus paying for both; whereas the attacker can run his dictionary attack on either. So the cost for the defender is ITERATIONS1+ITERATIONS2, whereas the cost for the attacker is only the smaller of the two. This is an advantage to the attacker.

• PBKDF2 is not the best in class; it can be executed very efficiently on a GPU. Bcrypt would be better (see this answer).

• You are relying on PBKDF2 behaving like a sort of "random oracle" with regards to the salt value. It so happens that in the case of PBKDF2, this is plausible (PBKDF2 is a chain of nested HMAC, starting with the salt). However, this is not a much studied property and you cannot count on it for just any password-based key derivation scheme. It would be safer to use cryptographic primitives the way they were intended to, because security comes from scrutiny, and exotic usage of algorithm has not, by definition, been extensively reviewed by cryptographers.

A better scheme would run one password hashing function (say, bcrypt), with one salt and one iteration count; and it would then expand the result with a Key Derivation Function (a fast one, e.g. HKDF) into a sequence of bytes that you would split into an encryption key, and a MAC key. This is, incidentally, how things are done in SSL. If you are in a hurry and don't want to implement an extra KDF, you can use in many cases a simple hash: compute SHA-256 on the bcrypt output, yielding 256 bits; the first 128 bits are for the encryption, the other half for the MAC.

---

In all generality, it is preferable to use authenticated encryption. CCM is an early attempt at an AE mode; better choices are EAX and GCM. The latter is fast becoming a standard for such things, and has been blessed by NIST. It is supports in SSL/TLS (since TLS-1.2) and is available in some widespread libraries (e.g. OpenSSL).