Message authentication code - Revision history

Babbage: Clean up/copyedit

2025-01-22T17:55:52Z

Clean up/copyedit

← Previous revision		Revision as of 17:55, 22 January 2025
Line 1:		Line 1:
	{{Short description\|Information used for message authentication and integrity checking}}		{{Short description\|Information used for message authentication and integrity checking}}
	{{Use dmy dates\|date=December 2023}}		{{Use dmy dates\|date=December 2023}}
	In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.		In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, it is used to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.

	==Terminology==		==Terminology==

R0paire-wiki: Reverting edit(s) by 2404:C0:4630:0:0:0:2CD:F4FE (talk) to rev. 1259641425 by PatrickDuc: Vandalism (UV 0.1.6)

2024-12-29T18:42:22Z

Reverting edit(s) by 2404:C0:4630:0:0:0:2CD:F4FE (talk) to rev. 1259641425 by PatrickDuc: Vandalism (UV 0.1.6)

← Previous revision		Revision as of 18:42, 29 December 2024
Line 1:		Line 1:
	{{Short description\|Information used for message authentication and integrity checking}}		{{Short description\|Information used for message authentication and integrity checking}}
	{{Use dmy dates\|date=December 2023}}		{{Use dmy dates\|date=December 2023}}
	In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to ~~…on-blockchain/token-contract~~ message content.		In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.

	==Terminology==		==Terminology==

2404:C0:4630:0:0:0:2CD:F4FE: 8170107008:AAEWMQsNlb6tdEbMl_6ZOjtuaGbOg9BD-eI

2024-12-29T18:41:16Z

8170107008:AAEWMQsNlb6tdEbMl_6ZOjtuaGbOg9BD-eI

← Previous revision		Revision as of 18:41, 29 December 2024
Line 1:		Line 1:
	{{Short description\|Information used for message authentication and integrity checking}}		{{Short description\|Information used for message authentication and integrity checking}}
	{{Use dmy dates\|date=December 2023}}		{{Use dmy dates\|date=December 2023}}
	In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to ~~the~~ message content.		In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to …on-blockchain/token-contract message content.

	==Terminology==		==Terminology==

PatrickDuc: The change reflects the fact that this partof the MAC system has no signing capability, only the capability to generate a MAC. Otherly said, a MAC is not a signature, as it is not generated from a proof of identity (i.e. an individual, secret pice of information such as a prvate key in PKI) but fram a shared proof of knowledge (i.e. a shared secret such as a symmetric cryptography key).

2024-11-26T07:38:42Z

The change reflects the fact that this partof the MAC system has no signing capability, only the capability to generate a MAC. Otherly said, a MAC is not a signature, as it is not generated from a proof of identity (i.e. an individual, secret pice of information such as a prvate key in PKI) but fram a shared proof of knowledge (i.e. a shared secret such as a symmetric cryptography key).

← Previous revision		Revision as of 07:38, 26 November 2024
Line 9:		Line 9:
	Informally, a message authentication code system consists of three algorithms:		Informally, a message authentication code system consists of three algorithms:
	* A key generation algorithm selects a key from the key space uniformly at random.		* A key generation algorithm selects a key from the key space uniformly at random.
	* A ~~signing~~ algorithm efficiently returns a tag given the key and the message.		* A MAC generation algorithm efficiently returns a tag given the key and the message.
	* A verifying algorithm efficiently verifies the authenticity of the message given the same key and the tag. That is, return ''accepted'' when the message and tag are not tampered with or forged, and otherwise return ''rejected''.		* A verifying algorithm efficiently verifies the authenticity of the message given the same key and the tag. That is, return ''accepted'' when the message and tag are not tampered with or forged, and otherwise return ''rejected''.

ClueBot NG: Reverting possible vandalism by 35.33.129.246 to version by Citation bot. Report False Positive? Thanks, ClueBot NG. (4352418) (Bot)

2024-10-20T13:54:18Z

Reverting possible vandalism by 35.33.129.246 to version by Citation bot. Report False Positive? Thanks, ClueBot NG. (4352418) (Bot)

← Previous revision		Revision as of 13:54, 20 October 2024
Line 1:		Line 1:
	{{Short description\|Information used for message authentication and integrity checking}}		{{Short description\|Information used for message authentication and integrity checking}}
	{{Use dmy dates\|date=December 2023}}		{{Use dmy dates\|date=December 2023}}
	In [[cryptography]], a '''message authentication code''' ('''MA''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its ~~authentity~~) and has not been changed (its ~~insanity~~). The MAC value allows ~~verifier~~ (who also possess a ~~huge fat~~ key) to detect any changes to the message content.		In [[cryptography]], a '''message authentication code''' ('''MAC'''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.

	==Terminology==		==Terminology==

35.33.129.246 at 13:54, 20 October 2024

2024-10-20T13:54:08Z

← Previous revision		Revision as of 13:54, 20 October 2024
Line 1:		Line 1:
	{{Short description\|Information used for message authentication and integrity checking}}		{{Short description\|Information used for message authentication and integrity checking}}
	{{Use dmy dates\|date=December 2023}}		{{Use dmy dates\|date=December 2023}}
	In [[cryptography]], a '''message authentication code''' ('''~~MAC'~~''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its ~~authenticity~~) and has not been changed (its ~~integrity~~). The MAC value allows ~~verifiers~~ (who also possess a ~~secret~~ key) to detect any changes to the message content.		In [[cryptography]], a '''message authentication code''' ('''MA''), sometimes known as an '''authentication tag''', is a short piece of information used for [[authentication\|authenticating]] and [[Data integrity\|integrity]]-checking a message. In other words, to confirm that the message came from the stated sender (its authentity) and has not been changed (its insanity). The MAC value allows verifier (who also possess a huge fat key) to detect any changes to the message content.

	==Terminology==		==Terminology==

Citation bot: Alter: title, template type. Add: chapter-url, volume, series, chapter, authors 1-1. Removed or converted URL. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Jay8g | Category:CS1 errors: invisible characters | #UCB_Category 5/6

2024-10-18T22:12:30Z

Alter: title, template type. Add: chapter-url, volume, series, chapter, authors 1-1. Removed or converted URL. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Jay8g | Category:CS1 errors: invisible characters | #UCB_Category 5/6

← Previous revision		Revision as of 22:12, 18 October 2024
Line 35:		Line 35:

	{{see also\|Key commitment}}		{{see also\|Key commitment}}
	While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to [[collision resistance]] or [[Preimage attack\|preimage security]] in hash functions. For MACs, these concepts are known as ''commitment'' and ''context-discovery'' security.<ref>{{Cite ~~journal~~ \|~~last~~=Bhaumik \|~~first~~=Ritam \|last2=Chakraborty \|first2=Bishwajit \|last3=Choi \|first3=Wonseok \|last4=Dutta \|first4=Avijit \|last5=Govinden \|first5=Jérôme \|last6=Shen \|first6=Yaobin \|date=2024 \|editor-last=Reyzin \|editor-first=Leonid \|editor2-last=Stebila \|editor2-first=Douglas \|title=~~The~~ ~~Committing~~ ~~Security~~ ~~of MACs~~ ~~with Applications~~ ~~to Generic Composition~~ \|url=https://link.springer.com/chapter/10.1007/978-3-031-68385-5_14 ~~\|journal=Advances in Cryptology – CRYPTO 2024~~ \|language=en \|location=Cham \|publisher=Springer Nature Switzerland \|pages=425–462 \|doi=10.1007/978-3-031-68385-5_14 \|isbn=978-3-031-68385-5}}</ref>		While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to [[collision resistance]] or [[Preimage attack\|preimage security]] in hash functions. For MACs, these concepts are known as ''commitment'' and ''context-discovery'' security.<ref>{{Cite book \|last1=Bhaumik \|first1=Ritam \|last2=Chakraborty \|first2=Bishwajit \|last3=Choi \|first3=Wonseok \|last4=Dutta \|first4=Avijit \|last5=Govinden \|first5=Jérôme \|last6=Shen \|first6=Yaobin \|chapter=The Committing Security of MACs with Applications to Generic Composition \|series=Lecture Notes in Computer Science \|date=2024 \|volume=14923 \|editor-last=Reyzin \|editor-first=Leonid \|editor2-last=Stebila \|editor2-first=Douglas \|title=Advances in Cryptology – CRYPTO 2024 \|chapter-url=https://link.springer.com/chapter/10.1007/978-3-031-68385-5_14 \|language=en \|location=Cham \|publisher=Springer Nature Switzerland \|pages=425–462 \|doi=10.1007/978-3-031-68385-5_14 \|isbn=978-3-031-68385-5}}</ref>

	==Implementation==		==Implementation==

Dimawik: /* Security */ similar issue for AEAD. It would be nice to have an example here of a practical attack, too

2024-10-18T21:26:59Z

Security: similar issue for AEAD. It would be nice to have an example here of a practical attack, too

← Previous revision		Revision as of 21:26, 18 October 2024
Line 34:		Line 34:
	MACs differ from [[digital signature]]s as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with [[symmetric encryption]]. For the same reason, MACs do not provide the property of [[non-repudiation]] offered by signatures specifically in the case of a network-wide [[shared secret]] key: any user who can verify a MAC is also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private key of a key pair, which is public-key cryptography.<ref name=":1" /> Since this private key is only accessible to its holder, a digital signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer non-repudiation. However, non-repudiation can be provided by systems that securely bind key usage information to the MAC key; the same key is in the possession of two people, but one has a copy of the key that can be used for MAC generation while the other has a copy of the key in a [[hardware security module]] that only permits MAC verification. This is commonly done in the finance industry.{{citation needed\|date=February 2013}}		MACs differ from [[digital signature]]s as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with [[symmetric encryption]]. For the same reason, MACs do not provide the property of [[non-repudiation]] offered by signatures specifically in the case of a network-wide [[shared secret]] key: any user who can verify a MAC is also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private key of a key pair, which is public-key cryptography.<ref name=":1" /> Since this private key is only accessible to its holder, a digital signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer non-repudiation. However, non-repudiation can be provided by systems that securely bind key usage information to the MAC key; the same key is in the possession of two people, but one has a copy of the key that can be used for MAC generation while the other has a copy of the key in a [[hardware security module]] that only permits MAC verification. This is commonly done in the finance industry.{{citation needed\|date=February 2013}}

			{{see also\|Key commitment}}
	While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to [[collision resistance]] or [[Preimage attack\|preimage security]] in hash functions. For MACs, these concepts are known as ''commitment'' and ''context-discovery'' security.<ref>{{Cite journal \|last=Bhaumik \|first=Ritam \|last2=Chakraborty \|first2=Bishwajit \|last3=Choi \|first3=Wonseok \|last4=Dutta \|first4=Avijit \|last5=Govinden \|first5=Jérôme \|last6=Shen \|first6=Yaobin \|date=2024 \|editor-last=Reyzin \|editor-first=Leonid \|editor2-last=Stebila \|editor2-first=Douglas \|title=The Committing Security of MACs with Applications to Generic Composition \|url=https://link.springer.com/chapter/10.1007/978-3-031-68385-5_14 \|journal=Advances in Cryptology – CRYPTO 2024 \|language=en \|location=Cham \|publisher=Springer Nature Switzerland \|pages=425–462 \|doi=10.1007/978-3-031-68385-5_14 \|isbn=978-3-031-68385-5}}</ref>		While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to [[collision resistance]] or [[Preimage attack\|preimage security]] in hash functions. For MACs, these concepts are known as ''commitment'' and ''context-discovery'' security.<ref>{{Cite journal \|last=Bhaumik \|first=Ritam \|last2=Chakraborty \|first2=Bishwajit \|last3=Choi \|first3=Wonseok \|last4=Dutta \|first4=Avijit \|last5=Govinden \|first5=Jérôme \|last6=Shen \|first6=Yaobin \|date=2024 \|editor-last=Reyzin \|editor-first=Leonid \|editor2-last=Stebila \|editor2-first=Douglas \|title=The Committing Security of MACs with Applications to Generic Composition \|url=https://link.springer.com/chapter/10.1007/978-3-031-68385-5_14 \|journal=Advances in Cryptology – CRYPTO 2024 \|language=en \|location=Cham \|publisher=Springer Nature Switzerland \|pages=425–462 \|doi=10.1007/978-3-031-68385-5_14 \|isbn=978-3-031-68385-5}}</ref>

	==Implementation==		==Implementation==

Morz25: /* Security */ Add committing security requirements for MACs

2024-10-18T18:27:36Z

Security: Add committing security requirements for MACs

← Previous revision		Revision as of 18:27, 18 October 2024
Line 33:		Line 33:

	MACs differ from [[digital signature]]s as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with [[symmetric encryption]]. For the same reason, MACs do not provide the property of [[non-repudiation]] offered by signatures specifically in the case of a network-wide [[shared secret]] key: any user who can verify a MAC is also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private key of a key pair, which is public-key cryptography.<ref name=":1" /> Since this private key is only accessible to its holder, a digital signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer non-repudiation. However, non-repudiation can be provided by systems that securely bind key usage information to the MAC key; the same key is in the possession of two people, but one has a copy of the key that can be used for MAC generation while the other has a copy of the key in a [[hardware security module]] that only permits MAC verification. This is commonly done in the finance industry.{{citation needed\|date=February 2013}}		MACs differ from [[digital signature]]s as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with [[symmetric encryption]]. For the same reason, MACs do not provide the property of [[non-repudiation]] offered by signatures specifically in the case of a network-wide [[shared secret]] key: any user who can verify a MAC is also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private key of a key pair, which is public-key cryptography.<ref name=":1" /> Since this private key is only accessible to its holder, a digital signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer non-repudiation. However, non-repudiation can be provided by systems that securely bind key usage information to the MAC key; the same key is in the possession of two people, but one has a copy of the key that can be used for MAC generation while the other has a copy of the key in a [[hardware security module]] that only permits MAC verification. This is commonly done in the finance industry.{{citation needed\|date=February 2013}}

			While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to [[collision resistance]] or [[Preimage attack\|preimage security]] in hash functions. For MACs, these concepts are known as ''commitment'' and ''context-discovery'' security.<ref>{{Cite journal \|last=Bhaumik \|first=Ritam \|last2=Chakraborty \|first2=Bishwajit \|last3=Choi \|first3=Wonseok \|last4=Dutta \|first4=Avijit \|last5=Govinden \|first5=Jérôme \|last6=Shen \|first6=Yaobin \|date=2024 \|editor-last=Reyzin \|editor-first=Leonid \|editor2-last=Stebila \|editor2-first=Douglas \|title=The Committing Security of MACs with Applications to Generic Composition \|url=https://link.springer.com/chapter/10.1007/978-3-031-68385-5_14 \|journal=Advances in Cryptology – CRYPTO 2024 \|language=en \|location=Cham \|publisher=Springer Nature Switzerland \|pages=425–462 \|doi=10.1007/978-3-031-68385-5_14 \|isbn=978-3-031-68385-5}}</ref>

	==Implementation==		==Implementation==

Frost: page moved: Changed link from UMAC to UMAC (cryptography) (×2) using Move+

2024-10-17T12:41:28Z

page moved: Changed link from UMAC to UMAC (cryptography) (×2) using Move+

← Previous revision		Revision as of 12:41, 17 October 2024
Line 35:		Line 35:

	==Implementation==		==Implementation==
	MAC algorithms can be constructed from other cryptographic primitives, like [[cryptographic hash function]]s (as in the case of [[HMAC]]) or from [[block cipher]] algorithms ([[OMAC (cryptography)\|OMAC]], [[CCM mode\|CCM]], [[Galois/Counter mode\|GCM]], and [[PMAC (cryptography)\|PMAC]]). However many of the fastest MAC algorithms, like [[UMAC]]-[[VMAC]] and [[Poly1305-AES]], are constructed based on [[universal hashing]].<ref>{{cite journal \|url=http://www.fastcrypto.org/vmac/draft-krovetz-vmac-01.txt\|title=VMAC: Message Authentication Code using Universal Hashing \|access-date=16 March 2010 \|journal=CFRG Working Group }}</ref>		MAC algorithms can be constructed from other cryptographic primitives, like [[cryptographic hash function]]s (as in the case of [[HMAC]]) or from [[block cipher]] algorithms ([[OMAC (cryptography)\|OMAC]], [[CCM mode\|CCM]], [[Galois/Counter mode\|GCM]], and [[PMAC (cryptography)\|PMAC]]). However many of the fastest MAC algorithms, like [[UMAC (cryptography)\|UMAC]]-[[VMAC]] and [[Poly1305-AES]], are constructed based on [[universal hashing]].<ref>{{cite journal \|url=http://www.fastcrypto.org/vmac/draft-krovetz-vmac-01.txt\|title=VMAC: Message Authentication Code using Universal Hashing \|access-date=16 March 2010 \|journal=CFRG Working Group }}</ref>

	Intrinsically keyed hash algorithms such as [[SipHash]] are also by definition MACs; they can be even faster than universal-hashing based MACs.<ref name="SipHash">{{cite web		Intrinsically keyed hash algorithms such as [[SipHash]] are also by definition MACs; they can be even faster than universal-hashing based MACs.<ref name="SipHash">{{cite web
Line 84:		Line 84:
	* [[Poly1305]]		* [[Poly1305]]
	* [[Authenticated encryption]]		* [[Authenticated encryption]]
	* [[UMAC]]		* [[UMAC (cryptography)\|UMAC]]
	* [[VMAC]]		* [[VMAC]]
	* [[SipHash]]		* [[SipHash]]