Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I'm a little unclear on how hash based MAC works... So I would like to know, is the security of your hash function as important as the security of the overall cipher? Basically, if you can crack the hash, does this compromise the cipher?
I understand that in most situations it isn't particularly feasible to crack either.
Based on your comment:
Correct... But it looks like many HMAC systems basically end up including a hash of the plaintext+key alongside the ciphertext. So it seems like cracking that hash would effectively compromise the entire encryption, no?
you may have a misunderstanding of how HMAC is used as part of a cryptosystem, which is reinforced by the opening line of the question.
The HMAC input is not the plaintext+key, but rather just the ciphertext, or just the plaintext. A separate key is used as part of the HMAC process to change the initial value of the hash function to a secret. The input is then hashed with the secret IV, and then the output is hashed again with a different secret IV. That key that generates the secret IVs is not the same as the key used by the cipher.
Current best practice is to MAC the ciphertext, and not even attempt decryption if the authentication fails. If the plaintext is MAC'd, decryption is required first. When HMAC is used, if the plaintext was MAC'd, an attacker can corrupt the MAC or ciphertext and resend multiple times, forcing the recipient to decrypt the message every time. If the cipher was vulnerable to a timing attack, this method could be used to recover cipher key material. The same security against timing attacks must be provided to the hash function, since a ciphertext MAC failure would not even touch the encryption key, but could allow recovery of the MAC key. In this respect, the security of HMAC is as important as the security of the cipher. This is also one of the reasons the MAC key and cipher key are different, so recovery of one would not compromise the other.
One of the other reasons to MAC the ciphertext when using HMAC, is that processing an identical plaintext results in an identical MAC, whereas the same plaintext results in a different ciphertext when encrypted correctly with most modes, which is an important required property for many applications.
Because of the way HMAC uses the hash, it is more robust than the hash used. The offline attack that would compromise HMAC is a preimage attack, which would recover the original message, specifically the part that generates the secret IVs. Because HMAC hashes twice, this is extremely difficult even with a broken hash like MD5.
Alex's answer also brings up an important point. Even after key rotation, a broken HMAC (key recovery) does not recover the message, and only allows forging a MAC using that key, which is now no longer used. The MAC key must be secure for the life of that key, which is generally short enough that a brute force attack to recover it is all but infeasible. The key should also be large enough for the same reason.
The security of the MAC is critical to achieving the confidentiality goal that you're using the cipher for in the first place (see: IND-CCA2).
That said, there's an interesting wrinkle here: the MAC's security is critical at the time you read the message. The cipher's security is critical forever. If you break the MAC on a message I read 6 years ago, nothing bad happens, but if you break the cipher, you now have the contents of the message which used to be secret.
