As I know CBC does not provide integrity for the message, thus HMAC is used to provide integrity for CBC message. Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC? And when do I need to use CBC and HMAC?


Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?

Generally, asking which one is better results in opinionated answers.

However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.

That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.

[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).

And when do I need to use CBC and HMAC?

You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.

However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).

EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).

There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.

  • 1
    $\begingroup$ "Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely. $\endgroup$ – ilkkachu Aug 13 '18 at 20:14
  • 1
    $\begingroup$ @ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know! $\endgroup$ – Maarten Bodewes Aug 13 '18 at 21:23

It sounds like you have one big misconception in your question:

Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?

The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.

The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:

  • CBC with HMAC

...when the correct comparison would be:

  • CBC with CBC-MAC
  • CBC with HMAC.

The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).


CBC provides message confidentiality, using a block cipher as the primitive.

CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:

  • the message is of fixed size;
  • the key is not reused;
  • an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).

HMAC also provides message integrity, using a Merkle–Damgård hash as the primitive.

When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).

There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.

The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:

  • there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
  • the requirement of different keys for CBC and CBC-MAC can be met;
  • the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).

Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.

  • $\begingroup$ append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong" $\endgroup$ – Martin Bonner supports Monica Aug 14 '18 at 9:11
  • $\begingroup$ @Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs. $\endgroup$ – fgrieu Aug 14 '18 at 9:49
  • $\begingroup$ I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad). $\endgroup$ – Martin Bonner supports Monica Aug 14 '18 at 12:02
  • $\begingroup$ @Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly. $\endgroup$ – fgrieu Aug 14 '18 at 12:35
  • $\begingroup$ Moxie Marlinspike coined this 'The Cryptographic Doom Principle'. See moxie.org/2011/12/13/the-cryptographic-doom-principle.html, where he states, 'if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.' $\endgroup$ – mti2935 Oct 24 '20 at 17:00

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.