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]

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]