Talk:CBC-MAC

CBC-MAC attack

Hi Quarl. I just noticed your contribution. Seems to be a relevant explanation of an attack that you added. However even for me as an old crypto geek it is not very comprehensible. So my first question is, what is a "PRF"? And if it means "Pseudo Random Function" which is my best guess then what does that have to do with it? (Well sure, the block crypto must behave like a random function to be a good crypto.) That first sentence of yours should perhaps be something like this "If the block crypto is secure then CBC-MAC is secure for fixed-length messages."

And I guess one fix to prevent the attack would be to use Merkle-Damgård length padding? So in essence not use CBC-MAC but instead first turn the block crypto into a secure hash using one of the methods described in One-way compression function and then use say HMAC to turn that hash into a MAC. Or perhaps use say OMAC or similar instead. (Although I do not know if OMAC is secure against the attack you described.)

--David Göthberg 07:43, 22 February 2006 (UTC)

Pseudorandom function = block cipher. I've changed the wording to be consistant. —Quarl ^(talk) 2006-02-22 09:21Z

There's an error in the description of the same-key vulnerability: the MAC is calculated using the plaintext, not the ciphertext; otherwise, it wouldn't work. Corrected this error.

--Illix, 2053h, 22 October 2006

I must admit, I do not understand 'the same key' attack. Since MAC on the receiver side is calculated by:

* decrypting the message,
* calculating MAC of decrypted text

when attacker will change any of bits before the last c_x-1 block, this will result in garbage after decypting, so calculated MAC will be totally different.
What am I missing? GiM (talk) 15:31, 11 February 2008 (UTC)

You are missing that there could be and encrypt-then-mac scheme, not the other way around, so the receiver would first check the mac on the encrypted text and then decrypt it. If this scheme is used, the mac check would be valid - the decryption of course would be garbled. —Preceding unsigned comment added by 94.193.216.239 (talk) 01:43, 6 December 2010 (UTC)

References for first attack method

I am currently searching for the source of the first attack ("Using the same key for encryption and authentication"), as that was not cited in the article. Does anyone know the original publication where the attack was first discussed?

Thanks in advance. --Malexmave (talk) 08:43, 26 June 2014 (UTC)

Update: Appearently, this attack was discussed in ISO/IEC 9797-1, but I cannot verify this right now, as I do not have access to the standard, as it is paywalled. --Malexmave (talk) 08:43, 26 June 2014 (UTC)

Security with fixed and variable-length messages

This section seems a bit over-complicated. Wouldn't it be easier to say "if an attacker can obtain message tags for short messages, a tag can be created for longer messages. Obtain the message-tags (m1, t1) and ( (m1 xor t1), t2 ) where the tag t1 is xor'd into the first block of m2; the second tag t2 will be valid for the longer message m1 || m2." Not going to edit the article; just a suggestion. John D. Goulden (talk) 02:47, 17 July 2015 (UTC)

I understand that the possibility to construct another message with a valid tag from two known shorter messages technically constitutes a breach of the algorithm. However, I'm struggling to think of a real-life example of where such a scenario would give an attacker a real benefit. Could you help me here? — Preceding unsigned comment added by 171.33.134.77 (talk) 09:40, 3 September 2015 (UTC)

Use as an Extractor, Use in Standards

CBC-MAC in NIST standards is not used as a MAC on its own. It's used within CCM in SP800-97 (that documents CCM in Wifi), SP800-121 Rev2 (that documents CCM in Bluetooth) and in SP800-90B (which specifies the USA of CBC-MAC as a stand-alone algorithm for entropy extraction - "Conditioning Component" in NIST speak).

So the only US stand-alone standardized use is not as a MAC, but as an extractor. That fits with all the problems with CBC-MAC as a MAC that are documented further up the page and alternative MACs exist that are approved by NIST (CMAC, HMAC etc). Those problems don't apply when CBC-MAC is used as an entropy extractor.

You could read this page and come away with the impression that CBC-MAC is a problematic MAC that no one should use. This is true for MAC uses, but it's alive and well and in use as an extractor in standardized and certified RNGs in many contexts.

This aspect of CBC-MAC - How it's actually used - is not addressed in the article. — Preceding unsigned comment added by David in oregon (talk • contribs) 17:37, 9 November 2021 (UTC)

I will add a section on the use of the algorithm. Dimawik (talk) 19:27, 21 June 2023 (UTC)

Insecurity in the lead

The just-added blanket statement in the lead about the CBC-MAC being deprecated is not correct, as it is used in multiple active standards. I have added the "variable length" qualifier to the sentence, but it does not capture all the subtleties. Perhaps, some other clarification can be applied? In any case, "it is advised to use alternatives" need a cite. Pinging @Jacob Valdemar:. Dimawik (talk) 19:23, 21 June 2023 (UTC)

@Dimawik Hello Dimawik, the statement about insecurity was based on my lecturer's slides at the university Master's level. It seems you are more knowledgeable than me in this regard. The comment "it is advised to use alternatives" is my own interpretation, and therefore you are right it should be removed - I'll do that right away. Thank you for reviewing my contribution. Jacob Valdemar (talk) 19:57, 21 June 2023 (UTC)

Attack due to incorrect use

This is a very large section devoted to attacks that are caused by the incorrect use. Two of them are based on modifying the IV - but the standard definition of CBC-MAC always has IV = 0, so these attacks are simply not possible. I suggest replacing these with a single sentence in the lead "Unlike the use of the CBC mode for encryption, CBC-MAC always sets the value of the initialization vector" IV) to zero. Pinging @Mhuxtable: Dimawik (talk) 01:11, 22 June 2023 (UTC)