Talk:Message authentication code

When is a MAC secure?

This article needs to contain a succinct statement of the properties a MAC function needs to have to be considered secure. The text describes only one property, resistance to "existential forgery under chosen-plaintext attacks", which appears to be strictly easier to satisfy than collision resistance for hash functions. However, if that was the whole requirement, the function $f_{k}(M)=H(M)$ where $H$ is a good hash function and $f_{k}(M)$ ignores $k$ (!), would be a good MAC, which is not the case. Thus there must be more requirements. What are they, exactly? Henning Makholm 20:11, 9 February 2007 (UTC)

The attacker has access to an oracle which produces a valid MAC tag given a message. They make q queries of the oracle, then they output a (message, tag) pair and exit. They succeed if the pair is valid and not one that was produced by the oracle. — ciphergoth 11:34, 22 February 2007 (UTC)

That makes sense. I have attempted to edit the article accordingly. Did I get it approximately right? –Henning Makholm 19:02, 22 February 2007 (UTC)

Resisting existential forgery

The article implies that security from existential forgery means that two different messages should not produce the same tag. However, existential forgery[[1]] actually means that an attacker is able to produce a valid message-tag pair, and does not have to show a collision.

Abejohnny 00:12, 22 February 2007 (UTC)

Yes, this is definitely an error. — ciphergoth 11:19, 22 February 2007 (UTC)

MIC actually needs "Confidentiality Protection" or Encryption

The claim that a MIC is like a MAC but needs to be "encrypted" seems highly dubious and I would need a citation or two to believe this claim was even made in good faith. It doesn't seem to pass an obviousness or giggle test -- in order to not be forgable the code must have been made using a secret the attacker lacks or the attacker will use the same technique to create their forgery. I can see how encryption could help if the encryption included integrity protection - but that wouldn't really be just encryption would it. —Preceding unsigned comment added by 72.52.84.194 (talk) 21:41, 14 July 2008 (UTC)

In all the cases I know, MIC is used instead of MAC for the one simple reason: MAC abbreviation is overloaded and, in particular, in communications it means Media Access Control. I have posted a request for citations. If none are provided, I am planning to revert to the old text stating that MIC and MAC are interchangeable. Dimawik (talk) 23:18, 17 January 2009 (UTC)

The text in the article is baloney. A MIC does not get secure just by encrypting it (think of known-plaintext under stream cipher encryption). Also, it is not valid to say that a MIC is less reliable than a MAC, because both can provide the same reliability in protection against accidental, unintentional modification. If you want to protect against intentional modification (forgeries), you have to use a keyed hash function (a MAC).

As I said below, the article is really bad, and is in need of a major rewrite.

Nageh (talk) 12:27, 6 April 2009 (UTC)

Integrity/Authentication

I don't agree with the sentence "MICs do not use secret keys and, when taken on their own, are therefore a much less reliable gauge of message integrity". I don't think that using a MIC is less reliable about integrity checking. Nevertheless, if I understand correctly, a MIC doesn't provide authentication as a MAC would do. —Shiningfm (talk) 22:59, 9 November 2008 (UTC)

That's true. MICs only allow for verifying whether a message was correctly transmitted from its origin to its receiver, but it does not allow for verifying its origin, which is acheived by MACs. The sentence you quoted compares apples with oranges. MICs and MACs serve for different purposes. If you want to verify integrity, MICs are enough (although MACs are fine). If you want to verify the origin, you need MACs.

Maybe the writer of that sentence meant to say that under the assumption that the MIC was not modified itself, it proves origin.

This is the case if the channel over which the MIC is sent is authenticated. Also it might seem improbable to the writer of the sentence that a MIC be forged even on an unauthenticated channel so it seems to be relatively "reliable". But it doesn't prove its origin so you can not really rely on it in this case.

132.231.1.241 (talk) 10:58, 7 January 2009 (UTC)

OK I agree with what you said. Nevertheless, I think that it should be explicitly explained in the article.

Anyway, if you only deal with MICs, we can assume that cases exist where we don't care much about who made the message. In such cases, wether a message is authenticated or not is not important, and so, an unauthenticated message is not less reliable than an authenticated one. Even if such cases don't exist, this is not the point here. Discussing this implies discussing the purpose of MICs, which is not the point here.

--Shiningfm (talk) 23:24, 9 January 2009 (UTC)

In all the cases I know, MIC is used instead of MAC for the one simple reason: MAC abbreviation is overloaded and, in particular, in communications it means Media Access Control. Cryptographers use MAC, communication engineers use MIC - but is is the same thing. For example, the IEEE 802.11 standard states,

3.84 message integrity code (MIC): A value generated by a cryptographic function. If the input data are changed, a new value cannot be correctly computed without knowledge of the cryptographic key(s) used by the cryptographic function. This is traditionally called a message authentication code (MAC), but the acronym MAC is already reserved for another meaning in this standard.

I have posted a request for citations. If none are provided, I am planning to revert to the old text stating that MIC and MAC are interchangeable. Dimawik (talk) 23:18, 17 January 2009 (UTC)

It also means Mandatory Access Control but I don't think that it is a good reason to state that one expression may be used instead of the other.

For example you could use md5 to check integrity of a file. In such a case, no key is used in the calculation. You don't check (and don't mind) about who produced the file.

On the other hand, when you use md5 in SSL, you use it with a key, to produce a HMAC. In such a case the MAC provides authentication of the one that produced the message.

There may exist some situations where one could use either one word or the other but I think that the article should make the difference between them.--Shiningfm (talk) 23:16, 18 January 2009 (UTC)

I don't think that it is a good reason to state that one expression may be used instead of the other - Well, it is used interchangeably in publications - and I have provided a source (and can provide more). Do you know of a source that defines the MIC and the MAC as two different things? Sorry for me being slow, but I did not understand the MD5 example. Without a secret key, the hash is just a checksum - not much different from, say, CRC32 (obvious advantages of a good hash over CRC32 notwithstanding) Dimawik (talk) 08:37, 19 January 2009 (UTC)

I think you are right. What I was taught is that a MIC is a checksum produced by a hash function. And a MAC is the same but using a key in the calculation. I can find this definition in some sites that make difference between MACs and MICs. But in the definitions of protocols, MIC is always employed where we could use MAC and I can't find a source (except crypto courses) where they are different things.

I think you could reverse.Shiningfm (talk) 11:17, 19 January 2009 (UTC)

A quote from a pretty reputable source (Fred B. Schneider) has been provided, so I have modified the text to reflect both positions. Dimawik (talk) 01:33, 9 February 2009 (UTC)

The article is not correct in saying that MIC is frequently used as a substitute for MAC. In correct terminology, it refers to an (unkeyed) hash function. Outside of the cryptographic community, either MIC or ICV is sometimes used to avoid mixture with other meanings. Btw, for the 802.11 reference given, MIC was really a MIC in the beginning (a CRC in the WEP protocol). Put aside, I wouldn't give credit to 802.11 sources in cryptographic questions after their WEP debacle.

(Btw, this article is horrible, needs a complete rewrite... don't know when I'll have time to do that, though.)

Nageh (talk) 21:47, 5 April 2009 (UTC)

Well, (1) MIC was not used in WEP terminology; ICV was used instead (2) The term MIC was coined by the 802.11i group, that produced the WPA and included quite a few well-known cryptographers (Niels Ferguson, Doug Whiting and Phillip Rogaway are among the ones I personally talked to regarding encryption for WiFi). (3) For obvious reasons the cryptographic meaning of MAC is being avoided in all communications standards that I know; either MIC or T is used instead. I agree that the article needs a rewrite, but please do not omit the fact that MIC is almost always just a MAC, it makes sense to mention also about the T notation (from the "Tag", as the MAC result is occasionally called too). Dimawik (talk) 21:30, 8 April 2009 (UTC)

I never mentioned which version of the 802.11 standard I was referring to. ;) But thanks for pointing out.

I think you've got a good point regarding the rationale of using the term MIC. But then I would rather say that in practice it almost always refers to a MAC, while in theory MIC is intended as a more general term, encompassing MACs, but possibly also digital signatures etc.

Tag is probably common, too, though I don't remember the T notation. Anyway, in contrast to MIC, tag is a more restrictive term in that it refers to the output of a MAC, only.

For those asking for references on guidelines/practice using the term MAC, also take a look at RFC 4949, item "Message Authentication Code".

Nageh (talk) 22:29, 9 April 2009 (UTC)

An example of the T notation can be found, for example, in the original GCM mode submission to NIST and most of the standards that were derived from it. I think that this article can be a good place to clear the meaning of confusing notations abound elsewhere. Dimawik (talk) 07:42, 10 April 2009 (UTC)

That is what I first meant and what I was taught in university... But do you know any references to entail that ? Except my personal notes I don't know any... —Shiningfm (talk) 22:43, 5 April 2009 (UTC)

What do you mean? Almost every book that covers classical cryptographic theory gives definitions on MIC/MDC vs. MAC... see the online HAC (Handbook of Applied Cryptography), chapter 9, for example: http://www.cacr.math.uwaterloo.ca/hac/

Regarding re-interpretation of acronyms, you can check various (wireless) protocol standards (MIC), or Internet RFCs (ICV).

Oh, and just to avoid (or add to the) confusion: a MIC/MAC refers to either the function, or the output (tag), while ICV only refers to the output.

Nageh (talk) 10:27, 6 April 2009 (UTC)

Great ! I should have searched more... Well, for sure the article needs rewriting ! —Preceding unsigned comment added by Shiningfm (talk • contribs) 09:11, 8 April 2009 (UTC)

Category:Cryptography vs. Category:Cryptographic algorithms vs. Category:Message authentication codes

Category:Message authentication codes is itself a category within Category:Cryptographic algorithms which is in turn is a category within Category:Cryptography. — Robert Greer (talk) 14:43, 6 March 2009 (UTC)

Roly1305 Hoangcuong95 (talk) 21:55, 8 February 2018 (UTC)

Code modification

Once the executable code modification is possible, any symmetric encryption (including MAC) that uses software is not useful anymore. This is very trivial and not MAC specific, and I do not think it should be mentioned here - perhaps, on a more generic page? Dimawik (talk) 04:37, 28 September 2009 (UTC)

Definitely not! Cryptography is about securing the communication channel, not the communication entities. If you can compromise such entity (through code exploits, stealing keys, whatever) security is trivially void. No need to mention that. Nageh (talk) 09:42, 28 September 2009 (UTC)

Bad SVG -> PNG thumbnail generation

The MAC.svg appears correctly formatted, but the auto-generated thumbnail (MAC.svg.png) is not. Dallasvaughan (talk) 16:01, 10 November 2009 (UTC)

encrypt-and-authenticate

It would help to have a discussion of the issues around combining MACs and encryption. For example, sign-then-encrypt vs encrypt-then sign. See for example http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html, which mostly discusses the asymmetric signature-and-encryption case. — Preceding unsigned comment added by 17.209.4.116 (talk) 19:07, 6 June 2011 (UTC)

There's a long discussion at "Should we MAC-then-encrypt or encrypt-then-MAC?". Could some of the sources mentioned in that discussion could be used a references for this Wikipedia article? --70.177.124.19 (talk) 13:23, 20 September 2015 (UTC)

No otp or code or verify 2404:3C00:353E:E6E0:6CC1:F68F:7DA2:F3A1 (talk) 02:36, 25 August 2023 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Message authentication code. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20061020212439/http://www.rsasecurity.com/rsalabs/node.asp?id=2177 to http://www.rsasecurity.com/rsalabs/node.asp?id=2177

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 13:03, 26 January 2018 (UTC)