12

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.

Matthew
  • 263
  • 1
  • 2
  • 9

3 Answers3

16

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.

Scott Pack
  • 15,217
  • 5
  • 62
  • 91
ixe013
  • 1,922
  • 15
  • 20
  • 4
    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 07:10
  • 2
    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: https://class.coursera.org/crypto/lecture/preview (Week 4) – pgolen May 12 '12 at 07:18
  • Yes, MD5 is weak, but that's not the point. We did not mention algorithm either. And what is a MAC other than an encrypted hash, like I proposed ? The message, along with the hash is encrypted. +Thanks for the link, I will use it next time I will give my introduction to cryptography class. – ixe013 May 13 '12 at 00:09
  • Best practice is to avoid using the same key for encryption and MAC, unless proven secure together (ie AES-CCM mode with some constraints) - for details: https://security.stackexchange.com/a/37881/2572 – Iiridayn Dec 29 '18 at 00:15
  • Is not the MAC to provide authenticity as much as it provides integrity? – zgulser Jan 28 '20 at 09:59
11

@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.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
2

A MAC or authentication tag (sometimes also called signature, although I think that's too confusing) can be used to provide message integrity and message authenticity. Message integrity means that an adversary - or transmission error - cannot change the message without it being detected by the receiver. For physical products we would call this tamper evident. Message authenticity shows that the message originated from a sender holding the secret key. Beware that both sides have the same secret.

Entity authentication is something different: the identification and authentication of parties within a protocol often relies on asymmetric cryptography rather than symmetric cryptography. In the TLS protocol the server is generally authenticated using a private key / certificate pair, while the messages are protected by a authentication tag generated using the symmetric session keys.

Most modes of operation will allow an attacker to make changes for specific bits. For instance, in the popular counter mode (CTR mode) any bit can be flipped, which will lead to a flipped bit in the plaintext at the same position. For CBC mode more bits will be changed, but the decryption and unpadding will still be unaffected (unless the last ciphertext block is changed significantly). One of the other answers underestimates the possibility of locally changing the plaintext by changing the ciphertext.

Generally a MAC is used over the ciphertext instead of over the plaintext. One of the reasons is that some modes of operation - such as CBC with PKCS#7 padding - are vulnerable all by themselves. If a padding or plaintext oracle is possible, CBC may actually allow an attacker to retrieve all the plaintext, without even attacking the cipher or gaining information on the key. For more information, see the question about MAC-then-encrypt and encrypt-then-MAC.

A MAC needs to be over both the ciphertext and the nonce or IV. If the IV or nonce are excluded the plaintext may still be altered by an adversary (if it is accessible by said adversary, of course).

Generally we try and use an authenticated cipher or AEAD cipher. These ciphers will automatically include any nonce or IV within the verification, so they should fully protect the plaintext.

Moreover, they may use a fast MAC that is insecure when used by itself, but is secure if it is combined by the cipher. Examples of these faster ciphers are ChaCha20/Poly1305 and AES-GCM. Both are for instance included in TLS 1.3.

There is even the IP hampered OCB mode which only requires a single pass of the cipher over the plaintext to both encrypt and provide integrity / authenticity. The Keccak sponge (used for SHA-3) may also be used for an authenticated mode.

Note that a MAC in itself doesn't protect against all attacks. For instance, if it is used within a transport protocol, it might be that messages are replayed if the same key is used. Furthermore, since a MAC also relies on symmetric keys, it could be that messages from A to B are captured and send back to A.

It is up to the higher level protocol to guard against such conditions. This is one of the reasons why transport security is hard. Just applying a MAC is not enough for a generic transport protocol. For transport security, use TLS, SSH or another established secure transport layer.

Maarten Bodewes
  • 4,602
  • 15
  • 29