up:: Foundations MOC

HMAC

HMAC (Hash-based Message Authentication Code) is a specific, standardized way to build a message authentication code out of a cryptographic hash function and a shared secret key, so that anyone holding the key can confirm a message arrived intact and was produced by someone who also holds the key. It pairs a hash like SHA-256 with the key in a fixed nested pattern, which is where the name comes from (HMAC-SHA-256, HMAC-SHA-384, and so on). It’s one of the most deployed primitives on the internet, sitting inside TLS, IPsec, JSON Web Tokens, and cloud API request signing, and because it’s symmetric it’s one of the pieces of cryptography that survives the arrival of a quantum computer largely intact.

Source: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

H. Krawczyk, M. Bellare, and R. Canetti, “HMAC, Keyed-Hashing for Message Authentication,” RFC 2104, February 1997, RFC 2104.

The short version:

1. HMAC proves two things about a message, that it wasn’t altered (integrity) and that it came from someone holding the shared key (authentication). It’s a MAC, not encryption, so it hides nothing.
2. It’s built from an ordinary hash function plus a secret key in a nested construction, standardized in RFC 2104 and NIST FIPS 198-1. Name the hash and you name the variant, HMAC-SHA-256 uses SHA-256.
3. It’s symmetric. The same secret both creates and checks the tag, so it can’t prove which of two key-holders sent a message, which is what separates it from a digital signature.
4. It’s everywhere real integrity matters cheaply, TLS key schedules, IPsec packet authentication, signed JWTs, and AWS-style API request signing.
5. It survives the quantum transition. Grover’s algorithm only square-root-speeds a brute-force key search, which a standard-size key and hash output already absorb, so HMAC needs no replacement the way RSA and ECDSA do.

Think of a tamper-evident seal that only works if you know a secret pattern. Anyone can drop a note in a shared lockbox, but to prove the note is genuinely yours and untouched, you press a stamp whose exact impression depends on both the note’s contents and a secret code only you and the recipient know. The recipient re-presses the stamp with the same code and checks that the impressions match. Change one word of the note and the impression stops lining up. Know the note but not the secret code, and forging a matching impression is out of reach. HMAC is that stamp done in math, the hash function makes the impression depend on every bit of the message, and the secret key is the code that makes it unforgeable.

What is HMAC?

HMAC is a construction, a recipe for turning any cryptographic hash function into a keyed message authentication code. A plain hash like SHA-256 takes a message and produces a fixed-size digest that anyone can compute, so on its own it proves a file wasn’t corrupted in transit but proves nothing about who produced it, since an attacker who alters the message can just recompute the hash. HMAC fixes that by folding a shared secret key into the hashing, so the resulting tag can only be produced (and only be checked) by someone who holds the key.

The “H” is the parameter. You pick the underlying hash and get the matching HMAC, and NIST approves HMAC with any FIPS-approved hash function, which today means the SHA-2 and SHA-3 families. The result is written as HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA3-256, and so on. HMAC was published as an IETF standard in RFC 2104 in 1997 and adopted by NIST as FIPS 198-1 in 2008, and it’s referenced by hundreds of other standards, which is why it became the default MAC of the internet.

The three properties HMAC delivers, and the one it deliberately does not:

1. Integrity. Because the tag is computed over the whole message, changing a single bit makes the recomputed tag fail to match. A passing check means the content is exactly what was sent.
2. Authentication of origin. Only a holder of the secret key could have produced a valid tag, so a passing check means the message came from a key-holder, not an outsider.
3. No confidentiality. HMAC is not encryption. The message travels in the clear (or is encrypted separately); the HMAC tag rides alongside it as proof, and hides nothing by itself.
4. No non-repudiation. Because two parties share the identical secret, either one could have produced any given tag. HMAC can’t single out which key-holder sent a message, which is the job a signature does instead.

Source: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

How does HMAC work?

HMAC hashes the message twice, wrapping it between two key-derived pads, and that nested structure is precisely what makes it secure even when the underlying hash has weaknesses a naive keyed hash would expose. The full definition from RFC 2104 and FIPS 198-1 is:

HMAC(K, m) = H( (K' XOR opad) || H( (K' XOR ipad) || m ) )

Reading that from the inside out, in order:

1. Prepare the key. The secret key K is turned into a block-sized key K'. If the key is longer than the hash’s internal block size it’s hashed down first; if shorter, it’s padded with zeros to fill the block.
2. Inner pass. K' is XORed with the inner pad ipad (the byte 0x36 repeated across the block), prepended to the message m, and the whole thing is hashed. This produces an intermediate digest bound to both the key and the message.
3. Outer pass. K' is XORed with the outer pad opad (the byte 0x5c repeated), prepended to that intermediate digest, and hashed again. The output is the HMAC tag.
4. Verify. The receiver, who holds the same key, recomputes the tag over the received message and compares it to the tag that arrived, using a constant-time comparison so the check itself leaks no timing information. Match means authentic and intact; mismatch means one or the other failed.

The two-layer nesting is the point. A tempting shortcut, just hashing the key prepended to the message (H(K || m)), is broken by a length-extension weakness in the common Merkle-Damgård hash designs like SHA-256, where an attacker can append data and produce a valid tag for a message they never fully knew. HMAC’s outer pass over the inner digest closes that hole. In fact HMAC’s security was later proven to hold as long as the hash’s internal compression function behaves like a pseudorandom function, a weaker and safer assumption than requiring full collision resistance, which is a large part of why HMAC kept its footing even as specific hashes like SHA-1 weakened.

Sources: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

M. Bellare, “New Proofs for NMAC and HMAC, Security Without Collision-Resistance,” CRYPTO 2006, IACR ePrint 2006/043, ePrint 2006/043.

What is HMAC used for?

HMAC is the workhorse integrity-and-authentication check wherever two parties already share a secret and need to confirm a message is genuine, cheaply and at scale. It shows up inside the protocols that carry most internet traffic, usually invisible until it’s the thing that stops a forged packet or a tampered token. The high-traffic surfaces:

Where it’s used	Typical variant	What it provides	Source
TLS 1.2 record protection and PRF	HMAC-SHA-256	Per-record integrity and the key-derivation PRF that expands the master secret	RFC 5246
TLS 1.3 key schedule (via HKDF)	HMAC-SHA-256 / -384	The HKDF key schedule that derives every session key is built entirely on HMAC	RFC 8446, RFC 5869
IPsec (ESP / AH) packet authentication	HMAC-SHA-256-128	Integrity and origin authentication for each IP packet in a VPN tunnel	RFC 4868
JSON Web Tokens (JWS, the HS family)	HMAC-SHA-256 (HS256)	A signed token whose integrity and authenticity an API can verify with the shared key	RFC 7515, RFC 7518
Cloud API request signing (AWS Signature v4)	HMAC-SHA-256	Proof that a request came from a holder of the secret access key and wasn’t altered in flight	AWS SigV4

Two patterns run through that table:

1. HMAC is the integrity half of a channel whose secrecy is handled separately. TLS and IPsec encrypt with a symmetric cipher and authenticate with HMAC (or an AEAD mode that plays the same role).
2. HMAC is the engine inside key derivation. HKDF (RFC 5869), the standard way to turn one shared secret into many session keys, is built entirely from HMAC calls. That means even TLS 1.3, which retired HMAC from directly protecting records in favor of AEAD ciphers, still relies on HMAC underneath for its entire key schedule.

Sources: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, RFC 8446.

H. Krawczyk and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” RFC 5869, May 2010, RFC 5869.

M. Jones, J. Bradley, and N. Sakimura, “JSON Web Signature (JWS),” RFC 7515, May 2015, RFC 7515.

How is HMAC different from a hash and from a digital signature?

HMAC sits between a plain hash and a digital signature, and the difference in each direction comes down to keys. A bare hash uses no key at all, so it detects accidental corruption but not deliberate tampering, since anyone who edits the message can recompute the digest. HMAC adds a shared secret, which upgrades a hash from “was this corrupted” to “was this altered or forged by an outsider.” A digital signature goes one step further and uses an asymmetric key pair, which buys a property HMAC structurally cannot offer.

That property is non-repudiation. Because HMAC’s key is shared, both parties can produce a valid tag, so a tag proves the message came from a key-holder without pinning down which one, meaning a recipient has no way to prove to a third party that the sender (rather than the recipient themselves) produced it. A signature is made with a private key that only one party holds, so it points to exactly one signer and holds up as evidence.

Property	Plain hash	HMAC	Digital signature
Key model	None	One shared secret (symmetric)	Public/private pair (asymmetric)
Detects tampering	Accidental only	Deliberate and accidental	Deliberate and accidental
Proves origin	No	Yes, to a fellow key-holder	Yes, to anyone
Non-repudiation	No	No	Yes
Speed and size	Fastest, smallest	Fast, small	Slower, larger
Quantum status	Survives (Grover only)	Survives (Grover only)	Classical schemes broken by Shor

The practical read is that you reach for HMAC when the same trusted parties share a key and just need fast, cheap proof that traffic is genuine, and for a signature when many independent verifiers need to check origin without sharing any secret, or when the proof has to stand up as evidence later.

Is HMAC safe against quantum computers?

Yes. HMAC survives the quantum transition, and this is the reassuring corner of the whole quantum-cryptography story. The primitives a quantum computer breaks outright are the public-key ones, RSA, ECDH, ECDSA, because Shor’s algorithm dissolves the specific number-theory problems they rest on. HMAC rests on no such structure. It’s a symmetric construction over a hash function, and the only general quantum attack that applies is Grover’s algorithm, which offers a square-root speedup on unstructured brute-force search and nothing better.

What that square-root speedup means for HMAC, concretely:

1. Key search stays out of reach. Forging an HMAC tag without the key means searching for the key, and Grover reduces the cost of brute-forcing an n-bit key from 2^n to about 2^(n/2). A 256-bit HMAC key drops to roughly 2^128 of effective work, which is astronomically infeasible, so a standard-size key already absorbs the entire quantum speedup with margin to spare.
2. The tag size is generous. HMAC’s output is as wide as its hash, 256 bits for HMAC-SHA-256, so the odds of guessing a valid tag stay negligible even against a quantum search.
3. HMAC’s security doesn’t lean on collision resistance. The property Grover-style attacks most affect in a hash is collision-finding, but HMAC was proven secure assuming only that the hash’s compression function is a good pseudorandom function, a weaker assumption, so quantum collision speedups don’t undermine it.

This matches NIST’s assessment that symmetric and hash-based primitives survive the quantum era while public-key primitives must be replaced. NIST’s guidance for symmetric cryptography is to keep key and output sizes at 256 bits where long-term security matters, which for HMAC means simply preferring HMAC-SHA-256 or wider, no new algorithm required. So while the signature and key-exchange layers of TLS and IPsec have to migrate to post-quantum standards, the HMAC-based integrity checks and key schedules inside those same protocols carry forward untouched.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NISTIR 8105.

What key size and hash should you use with HMAC?

The safe default is HMAC with a SHA-2 or SHA-3 hash and a key at least as long as the hash’s output, and for long-term and post-quantum-comfortable security that means HMAC-SHA-256 with a 256-bit key or wider. NIST SP 800-107 and FIPS 198-1 set the guidance, and the moving parts are the hash choice, the key length, and (optionally) how much of the tag you keep:

Parameter	Guidance	Why
Hash function	SHA-256 or wider, from the SHA-2 or SHA-3 families	FIPS-approved and unbroken; avoid HMAC-MD5 and de-emphasize HMAC-SHA-1 for new designs
Key length	At least the hash output length (256 bits for HMAC-SHA-256)	A key shorter than the output is the weakest link; a key longer than the block buys nothing and gets hashed down
Key quality	Full-entropy random key from a good RNG	HMAC’s strength is the key’s unpredictability, not a password a human picked
Tag truncation	Keep at least 128 bits if truncating	Some protocols truncate (IPsec’s HMAC-SHA-256-128) to save space, but over-truncation weakens forgery resistance

The one gotcha worth stating plainly is that HMAC’s security is only ever as good as its key. HMAC with a guessable or low-entropy key (a short password, a hardcoded string) is trivially forgeable no matter how strong the hash is, which is why HMAC keys should be full-length random values, and why a raw shared secret is usually run through a KDF before it’s used as an HMAC key.

Source: NIST, “Recommendation for Applications Using Approved Hash Algorithms,” SP 800-107 Rev. 1, August 2012, SP 800-107r1.

Common misconceptions

1. “HMAC encrypts the message.” It doesn’t. HMAC is a MAC, it proves integrity and authenticity while leaving the message fully readable. Confidentiality is a separate job done by an encryption algorithm, and a protocol like TLS runs both side by side.
2. “HMAC is a digital signature.” Both prove a message is genuine, but HMAC uses one shared secret, so it can’t provide non-repudiation or let an outside party verify origin. A signature uses a private key only one party holds, which is what makes it evidence.
3. “A quantum computer breaks HMAC.” No. HMAC is symmetric, so only Grover’s algorithm applies, and its square-root speedup is fully absorbed by a standard 256-bit key. HMAC needs no post-quantum replacement, unlike RSA and ECDSA.
4. “HMAC is unsafe because SHA-1 is broken.” HMAC-SHA-1 held up far longer than plain SHA-1, because HMAC’s security rests on the compression function being a good pseudorandom function rather than on collision resistance. Even so, new designs should use HMAC-SHA-256 or wider.
5. “You can just hash the key and message together to make a MAC.” The naive H(key || message) construction is vulnerable to a length-extension attack on common hash designs. HMAC’s nested double-hash structure exists specifically to close that hole, which is why you use HMAC rather than rolling your own.
6. “A longer key always makes HMAC stronger.” A key longer than the hash’s block size gets hashed down to block size first, so past that point extra length adds nothing. The size that matters is having a full-entropy key at least as long as the hash output.

Questions people ask

Is HMAC still safe to use today? Yes. HMAC with a modern hash like SHA-256 and a proper random key is one of the most trusted primitives in cryptography, standardized in RFC 2104 and FIPS 198-1 and deployed across TLS, IPsec, and countless APIs. It has no known practical break and survives the quantum transition.

What does HMAC actually protect against? Tampering and forgery. HMAC lets a recipient confirm that a message wasn’t altered in transit and that it came from someone holding the shared key. It does not keep the message secret, that’s the job of encryption, which is usually applied alongside it.

What’s the difference between HMAC and a hash like SHA-256? A bare hash uses no key, so anyone can compute it, which means it catches accidental corruption but not deliberate tampering. HMAC folds a secret key into the hash, so only a key-holder can produce or verify a valid tag, which is what turns a hash into proof of authenticity.

Do I have to replace HMAC for post-quantum security? No. HMAC is symmetric, and the only quantum attack that applies, Grover’s algorithm, is fully absorbed by a 256-bit key. Prefer HMAC-SHA-256 or wider and you’re set. The parts of your stack that need post-quantum migration are the public-key pieces, the signatures and key exchange.

Which hash should I pick for HMAC? Use a SHA-2 or SHA-3 hash, with HMAC-SHA-256 the sensible default for most systems and HMAC-SHA-384 or wider where you want extra long-term margin. Avoid HMAC-MD5 entirely, and de-emphasize HMAC-SHA-1 in new designs even though it’s held up better than plain SHA-1.

Is HMAC the same as HKDF? No, but HKDF is built from HMAC. HKDF (RFC 5869) is a key-derivation function that uses HMAC as its internal engine to turn one shared secret into multiple session keys. It’s the mechanism behind the TLS 1.3 key schedule, which is one reason HMAC remains load-bearing even where AEAD ciphers replaced it for record protection.

Why does HMAC hash the message twice? The double, nested hashing is what defends against length-extension attacks that would break a naive single-hash keyed construction on common hash designs. The inner pass binds the key and message, and the outer pass over that result seals it, and this structure is also what lets HMAC’s security proof rest on a weaker, safer assumption about the hash.

Can HMAC prove who sent a message to a court or third party? No. Because the key is shared, either party could have produced any valid tag, so HMAC can’t provide non-repudiation. When you need a proof of origin that stands up to an outside party, you use a digital signature with its private key held by exactly one signer.

---

Everything here is the map, given freely. When your team needs its cryptography inventoried and sorted into what survives the quantum transition and what has to move, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.