Hashed message authentication code: Difference between revisions
imported>Sandy Harris No edit summary |
mNo edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{PropDel}}<br><br>{{subpages}} | |||
HMACs use a [[cryptographic hash]] algorithm and a [[cryptographic key]]. The sender generates the HMAC from the message and the key; the receiver | A '''hashed message authentication code''' or '''HMAC''' is a [[cryptography | cryptographic]] technique for providing [[information security#integrity|data integrity protection]] and [[information security#source authentication|source authentication]]. The term '''HMAC''' is often used for both the HMAC algorithm and for the HMAC token that is appended to a message. | ||
HMACs use a [[cryptographic hash]] algorithm and a [[cryptographic key|symmetric key]] that is shared by the sender and the receiver of the message. The sender generates the HMAC from the message and the key; the receiver also computes the HMAC of the message he received using the shared key, then compares the result with the HMAC he received with the message. | |||
If HMAC verification succeeds, the receiver knows not only that the message is unchanged since the hash was generated (which he would know with any hash algorithm), but also that whoever generated the HMAC knew the appropriate key. This prevents an attacker without the key from altering a message and generating a valid hash for the changed version. HMACs prevent [[man-in-the-middle attack]]s. | If HMAC verification succeeds, the receiver knows not only that the message is unchanged since the hash was generated (which he would know with any hash algorithm), but also that whoever generated the HMAC knew the appropriate key. This prevents an attacker without the key from altering a message and generating a valid hash for the changed version. HMACs prevent [[man-in-the-middle attack]]s. | ||
| Line 13: | Line 15: | ||
}}</ref> gives a general definition of the HMAC technique for this usage. More detail is in RFC 2202, RFC 2403, RFC 2404, RFC 2085, RFC 2857, RFC 4635, RFC 4650. | }}</ref> gives a general definition of the HMAC technique for this usage. More detail is in RFC 2202, RFC 2403, RFC 2404, RFC 2085, RFC 2857, RFC 4635, RFC 4650. | ||
Many applications use both a [[block cipher]] for secrecy and an HMAC for data authentication | Many applications use both a [[block cipher]] for secrecy and an HMAC for data authentication. Such a system must make two passes through the data, one to encrypt it and one to hash it. There is recent work on the design of algorithms that can do both in one pass. Many of the proposed solutions take the form of new [[Block_cipher_modes_of_operation#Dual_use_modes|modes of operation]] for block ciphers. | ||
== References == | == References == | ||
{{reflist|2}} | {{reflist|2}}[[Category:Suggestion Bot Tag]] | ||
Latest revision as of 06:00, 26 August 2024
| This article may be deleted soon. | ||
|---|---|---|
 A hashed message authentication code or HMAC is a cryptographic technique for providing data integrity protection and source authentication. The term HMAC is often used for both the HMAC algorithm and for the HMAC token that is appended to a message. HMACs use a cryptographic hash algorithm and a symmetric key that is shared by the sender and the receiver of the message. The sender generates the HMAC from the message and the key; the receiver also computes the HMAC of the message he received using the shared key, then compares the result with the HMAC he received with the message. If HMAC verification succeeds, the receiver knows not only that the message is unchanged since the hash was generated (which he would know with any hash algorithm), but also that whoever generated the HMAC knew the appropriate key. This prevents an attacker without the key from altering a message and generating a valid hash for the changed version. HMACs prevent man-in-the-middle attacks. IPsec uses an HMAC for packet-level authentication. RFC 2104 [1] gives a general definition of the HMAC technique for this usage. More detail is in RFC 2202, RFC 2403, RFC 2404, RFC 2085, RFC 2857, RFC 4635, RFC 4650. Many applications use both a block cipher for secrecy and an HMAC for data authentication. Such a system must make two passes through the data, one to encrypt it and one to hash it. There is recent work on the design of algorithms that can do both in one pass. Many of the proposed solutions take the form of new modes of operation for block ciphers. References
|
||
