Talk:Message authentication code

Cryptography: Computer science Unassessed

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

Template:CryptographyReader

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]