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)

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)