I understand the difference between MAC (eg. hmac_sha256, etc.) and Symmetrical Encryption (eg. rc4, etc.), but my question is what advantage does MAC solve that using encryption doesn't?

I know that MAC is used to verify that the message is both from the intended source, and did not get tampered though transmission by hashing the message with a secret key.

If you encrypt the message with rc4 (or any other algorithm, strength beside the point), then does this not accomplish the same result, the receiver would still need to know the secret key to decrypt the message.

The only difference I can think of is with MAC the message itself is plain text, so the authentication of the message is very fast. So is performance the only difference? Or is it the fact that the message contents are not confidential and you only want to validate whether it's genuine or not.

Any information on these two concepts would be greatly appreciated.


Encryption provides confidentiality, a MAC provides integrity. Using encryption alone makes your messages vulnerable to a ciphertext only attack.

An example will make it more clear. Say you send a message that says:

M = "transfer 100$ to account 591064"

The sender, with the symmetric key, can encrypt the message and send E(M). No one should be able to send a valid message other than the holder of the key. You have confidentiality covered.

But an attacker could alter the ciphertext to make it say something else when decrypted. Obviously, the larger the message and the more structure it has, the harder it gets to carry out in practice.

Now if you use a MAC along with encryption, you will be able to detect changes to the cipher text because the MAC will not compute. In our example, if you use the same key for encryption and MAC, then you can change your message to:

M = "transfer 100$ to account 591064|a46c0db15acdd36b4e92a82e5dc6c14f"

and encrypt it, again sending E(M). The hash is encrypted (that's your MAC), the message is encrypted (for confidentiality). That way, you make it computationally impossible to alter the cipher text and come up with a valid message, even if your message is a single, random byte.

Choosing the best hash, encryption and key length is another story.

In conclusion:

  • Encryption does not provide integrity by itself
  • MAC (integrity) does not provide confidentiality by itself

You often have to combine cryptographic primitives to achieve many security properties.

|improve this answer|||||
  • 3
    Note that depending on the encryption algorithm (or mode of operation, in the case of a block cipher), simply appending a (unkeyed) hash of the message before encrypting might not make a valid MAC. [For example, it will fail for modes like CTR and OFB, if the attacker can guess the message's content.] – Paŭlo Ebermann May 11 '12 at 12:32
  • This looks like it answers my question, this is to prevent the receiving end from trying to decypher garbage (hacked) text, and prevent the hacker from stumbling upon a valid message? – Matthew May 11 '12 at 13:30
  • Yes, I added a conclusion to sum it up. – ixe013 May 11 '12 at 14:13
  • Your example with md5 used as MAC is wrong. Attacker is able to compute MD5 without problem, because there is no key. You should use HMAC for that. Attacker is some cases is able to encrypt message without knowing the key. For example Padding Oracle Attack may allow this. – pgolen May 12 '12 at 7:10
  • 1
    Moreover you suggested mac-then-encrypt approach, which is incorrect. You should use encrypt-then-mac approach or you should use Authenticated Encryption modes like GCM, CCM or EAX. Here is more info on authenticated encryption: class.coursera.org/crypto/lecture/preview (Week 4) – pgolen May 12 '12 at 7:18

@ixe013 explains it well. Encryption and MACs serve a different purpose.

If you need integrity, you need to use a MAC. Encryption does not provide integrity.

If you need confidentiality, you need to use both encryption and a MAC. You might think that encryption would be enough in this case (no need for a MAC), but you'd be wrong. See Don't use encryption without message authentication.

That said, in practice you shouldn't roll your own crypto. That means, among other things, you shouldn't try to build up some combination of cryptographic primitives to achieve your application needs: you shouldn't think at the level of encryption algorithms and message authentication codes. Doing so is error-prone, and rarely is it necessary. Instead, you should use an existing well-vetted cryptographic system (TLS, GPG, SSH, OpenVPN, IPSec, etc.) to provide a secure communication channel or a secure storage system. If you do that, the existing cryptographic system will take care of these details for you. Cryptographers have slaved over these details, so that you don't need to.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.