I have a message and I want to verify its integrity and authenticity.

I have a shared secret (key) that is not used for other encryption.

Is it safe to send a plaintext message containing all the data I want, and to verify its integrity and authenticity using CBC-MAC?

I mean - of course the data is not secret, but do I have a risk of someone changing the message / MAC and messing with my message? Is it possible to deduct the Key?


1 Answer 1


Yes, this is exactly what a message authentication code is for. Its job is to prevent an attacker from tampering with your message, or from forging completely bogus messages. For a secure MAC, it should not matter what these messages contain.

(And no, a secure MAC cannot compromise your key; if it did, it would by definition not be secure, since an attacker could use the key to forge messages.)

However, you probably don't want to use classic CBC-MAC if you can avoid it, since it's not provably secure when used on arbitrary messages. (It is secure when the messages are prefix-free, i.e. when no valid message can be a prefix of another valid message, but this can be somewhat tricky to ensure.) It's better to use CMAC or one of the other modern cipher-based MACs (OMAC2, PMAC, etc.) instead; unlike CBC-MAC, these have security proofs that don't require any special assumptions about the messages.

Also note that a MAC does not prevent an attacker from:

  • blocking or delaying the delivery of valid messages,
  • re-sending verbatim duplicates of previously captured messages, or
  • tampering with any metadata (such as sender or receiver IDs) that is not included in the MAC input.

To protect against such attacks, you'll likely want to include an incremental message ID and/or a timestamp in your messages, as well as some way of identifying who sent the message and to whom. You also need to make sure that these extra fields are actually included as part of the MAC input, so that the attacker cannot change them.

Ps. When combining encryption with a MAC, the reason why we usually encrypt the message first is actually the opposite of what you may think: it's not meant to hide the plaintext from the MAC, but to protect the encryption scheme from chosen-ciphertext attacks by ensuring that only ciphertexts with a valid MAC are ever passed to the decryption code.

(Also, not all MACs are guaranteed to be privacy-preserving, which means that, if you calculate the MAC on the plaintext and then transmit the MAC output unencrypted, an attacker might theoretically learn something about the plaintext just by observing the MAC output. That said, most commonly used MACs — including CBC-MAC, when used properly — are privacy-preserving. And in any case, this doesn't matter for you, since you're transmitting the whole message unencrypted anyway.)

  • $\begingroup$ What kind of "security issues" and what "tricky work arounds"? It is highly preferable that I manage to utilize cbc-mac $\endgroup$
    – Yoav R.
    Commented Sep 3, 2015 at 22:28
  • $\begingroup$ Read the Wikipedia article I linked to. The main issue is that the inputs to CBC-MAC need to be prefix-free, i.e. no valid message can be a prefix of another valid message. (One way to achieve this is to prepend a length field to the messages.) $\endgroup$ Commented Sep 3, 2015 at 22:33
  • $\begingroup$ are you 100% sure, that sending all the data as plaintext and just adding the MAC(created by applying CBC-MAC on the message) is secured(integrity and authenticity wise)? $\endgroup$
    – Yoav R.
    Commented Sep 4, 2015 at 8:41
  • 3
    $\begingroup$ @YoavR. MAC's don't place any requirements on the input (other than a usually very high amount of input if a 128 bit block cipher is used). As already indicated there are additional requirements to make a MAC secure, especially CBC-MAC. If you are still unsure, please indicate which specific doubts you are having instead of simply doubting the answer or - even worse - the person writing the answer. If that's not enough, hire an expert instead of relying on a Q/A site. $\endgroup$
    – Maarten Bodewes
    Commented Sep 4, 2015 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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