up:: Foundations MOC

FIPS 198-1

FIPS 198-1 is the NIST federal standard, titled “The Keyed-Hash Message Authentication Code (HMAC),” that specifies HMAC, the keyed-hash message authentication code. It defines exactly how a cryptographic hash function such as SHA-256 combines with a shared secret key to produce a short authentication tag that proves a message is intact and came from a key holder. Published in July 2008 to supersede the original FIPS 198 (2002), it approves HMAC with any iterative NIST-approved hash function, which is why the variants are named for the hash they carry, like HMAC-SHA-256. Because HMAC is symmetric, its tag rests on no problem Shor’s algorithm can solve, so FIPS 198-1 carries through the quantum transition intact while the public-key standards like FIPS 186-5 have to be replaced.

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

The short version:

1. FIPS 198-1 is NIST’s standard for HMAC, published July 2008, superseding FIPS 198 (2002). It defines the construction; the full mechanism deep-dive lives in the HMAC note.
2. It specifies how any approved iterative hash (the SHA-2 and SHA-3 families) combines with a secret key to make an authentication tag, so each variant is named for its hash, and HMAC-SHA-256 uses SHA-256.
3. The tag proves integrity and authentication while leaving the message fully readable. HMAC is a MAC, and encryption is a separate job.
4. Companion guidance on key length, hash strength, and tag truncation lives in NIST SP 800-107, and NIST is consolidating both into a planned successor, SP 800-224.
5. It survives quantum computers. HMAC is symmetric, so only Grover’s algorithm applies, and a 256-bit key absorbs it, so FIPS 198-1 needs no post-quantum replacement the way RSA and ECDSA do.

Think of FIPS 198-1 as the government-published instruction sheet for a single trusted tool, the secret-keyed seal. It doesn’t hand you the seal; it writes down the exact procedure so that any two parties, following the sheet with the same hash and the same key, press an identical impression from the same message. Name the hash the sheet points at and you’ve named the seal, so HMAC-SHA-256 uses SHA-256. When a protocol like TLS or a cloud API says “authenticate it with HMAC,” this instruction sheet is the reference it’s pointing at.

What is FIPS 198-1?

FIPS 198-1 is a Federal Information Processing Standard titled “The Keyed-Hash Message Authentication Code (HMAC),” issued by the National Institute of Standards and Technology in July 2008 as the first revision of FIPS 198. A FIPS is mandatory for U.S. federal agencies and the cryptographic modules they buy, and this one governs one specific mechanism: how to turn a hash function and a shared secret key into a keyed message authentication code that confirms a message was neither altered in transit nor produced by an outsider.

The standard superseded the original FIPS 198, which was published March 6, 2002, and its abstract states its scope in one line: it “describes a keyed-hash message authentication code (HMAC), a mechanism for message authentication using cryptographic hash functions.” Because insurers, sector regulators, and procurement programs align to NIST, FIPS 198-1 functions as the practical reference for keyed message authentication far beyond federal systems, which is a large part of why HMAC became the default MAC across the internet.

FIPS 198-1 defines the HMAC mechanism itself. It does not define the hash functions HMAC runs on, those live in the separate hash standards FIPS 180-4 and FIPS 202, and it does not set the rules for how HMAC gets used inside a larger protocol, which live in documents like SP 800-107 and the individual protocol specifications.

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

What does FIPS 198-1 specify?

FIPS 198-1 specifies the HMAC algorithm: the inputs it takes, the fixed nested way it folds a secret key into a hash, and the tag it outputs. Given a message, a secret key, and an approved hash function H, the standard defines the tag as a double, key-wrapped hashing:

HMAC(K, text) = H( (K0 ⊕ opad) || H( (K0 ⊕ ipad) || text ) )

The standard fixes every piece of that formula: it prepares the key into a block-sized value K0, XORs it against an inner pad and an outer pad, hashes the message under the inner pad, then hashes that result under the outer pad, and optionally truncates the final output to a shorter tag. It also specifies that a verifier recomputes the tag over the received message with the same key and accepts the message only if the two tags match.

What FIPS 198-1 deliberately leaves out is as telling as what it includes. It does not define H itself, the SHA functions are specified elsewhere, and it does not dictate how HMAC is wired into TLS records, IPsec packets, or signed tokens, which each protocol handles in its own specification. FIPS 198-1 is the primitive; the full walk-through of why the nested structure is secure, and where HMAC is deployed, lives in the HMAC note.

Sources: 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.

Which hash functions can you use with FIPS 198-1?

FIPS 198-1 approves HMAC with any iterative NIST-approved cryptographic hash function, which in practice means the SHA-2 family (from FIPS 180-4) and the SHA-3 family (from FIPS 202). The hash is a parameter you plug in, and the resulting MAC is named for it, so the security and the output size of the HMAC follow directly from the hash you pick. The common variants:

HMAC variant	Underlying hash	Hash standard	Tag size	Status
HMAC-SHA-256	SHA-256	FIPS 180-4	256-bit	Approved, the everyday default
HMAC-SHA-384	SHA-384	FIPS 180-4	384-bit	Approved, extra long-term margin
HMAC-SHA-512	SHA-512	FIPS 180-4	512-bit	Approved, widest margin
HMAC-SHA3-256	SHA-3	FIPS 202	256-bit	Approved, sponge-based alternative
HMAC-SHA-1	SHA-1	FIPS 180-4	160-bit	Approved but de-emphasized for new designs
HMAC-MD5	MD5	Not a NIST standard	128-bit	Not approved, avoid

Two things fall out of that table. HMAC-SHA-256 or wider is the sensible default for new work, because a wide, unbroken SHA-2 or SHA-3 hash carries the whole construction comfortably. And HMAC held up remarkably well even where the underlying hash weakened, HMAC-SHA-1 stayed usable long after plain SHA-1 fell to a collision attack, because HMAC’s security rests on the hash’s compression function behaving like a pseudorandom function rather than on full collision resistance. That resilience is one reason FIPS 198-1 pins the construction while leaving the hash choice open.

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

NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, FIPS 180-4.

How does the FIPS 198-1 HMAC construction work?

The construction hashes the message twice, wrapping it between two key-derived pads, and FIPS 198-1 specifies each step precisely so that any correct implementation produces identical tags. Reading the formula from the inside out:

1. Prepare the key. The secret key K is turned into a block-sized key K0, where the block size B comes from the hash. If K is exactly B bytes, K0 equals K. If it’s shorter, K is padded with trailing zeros to fill the block. If it’s longer than B, K is hashed down first and then zero-padded.
2. Inner pass. K0 is XORed with the inner pad ipad (the byte 0x36 repeated across the block), prepended to the message, and hashed, producing an intermediate digest bound to both the key and the message.
3. Outer pass. K0 is XORed with the outer pad opad (the byte 0x5C repeated), prepended to that intermediate digest, and hashed again. The result is the HMAC tag.
4. Verify. The receiver, holding the same key, recomputes the tag over the received message and compares it against the tag that arrived, ideally with a constant-time comparison so the check leaks no timing information.

The reason the standard mandates this specific two-layer nesting, rather than the tempting shortcut of hashing the key and message together, is that a naive keyed hash is vulnerable to a length-extension attack on the common Merkle-Damgard hash designs, and HMAC’s outer pass closes that hole. The full security argument, the length-extension trap, and the deployment surfaces are covered in depth in the HMAC note; FIPS 198-1’s job is to fix the exact procedure so the primitive is interoperable and correct everywhere.

Sources: 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.

What does FIPS 198-1 say about key length and tag truncation?

FIPS 198-1 ties HMAC’s strength to two operator choices, the key length and how much of the tag you keep, and it gives guidance on both while pointing to NIST SP 800-107 for the detailed rules. The parameters and what the standard says about each:

Parameter	What FIPS 198-1 specifies
Hash function H	Any approved iterative hash, from the SHA-2 or SHA-3 families
Block size B	Set by the hash (for example 64 bytes for SHA-256, 128 bytes for SHA-512)
Output length L	The hash’s digest size (32 bytes for HMAC-SHA-256)
Key K0	Equals K if K is B bytes, zero-padded if shorter, hashed then padded if longer
Recommended key length	At least L bytes, and a key shorter than L lowers the security strength
Tag truncation	The leftmost t bytes of the output may be kept, with length guidance in SP 800-107

The load-bearing point is that HMAC’s security is only ever as strong as its key. FIPS 198-1 recommends a key at least as long as the hash output and drawn from a good source of randomness, because a short or guessable key is the weakest link no matter how strong the hash is. Truncation is a space-saving option some protocols use (IPsec’s HMAC-SHA-256-128 keeps 128 bits), and the guidance is to keep enough tag that a blind forger’s one-in-2 to the t-bits chance stays negligible. The detailed minimums for key length, hash strength, and truncation are set in the companion document, SP 800-107.

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

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

What is FIPS 198-1’s status, and is it being replaced?

FIPS 198-1 is a final, current standard, in force since July 2008, and it remains the authoritative U.S. specification for HMAC. NIST has announced that it plans to move the content of FIPS 198-1, together with the hash-usage guidance in SP 800-107, into a single new NIST Special Publication, SP 800-224, which is in draft with a public-comment window that opened in 2025. That consolidation is a housekeeping and modernization move rather than a security change, and it does not deprecate HMAC or alter the construction.

Two clarifications matter for anyone reading the tea leaves:

1. The planned revision is not a quantum retreat. Unlike the classical signature and key-exchange standards, HMAC has no quantum-driven deadline. The move to SP 800-224 tidies the documentation; it does not replace the algorithm the way FIPS 204 replaces the signatures in FIPS 186-5.
2. HMAC itself carries forward untouched. The variants named in FIPS 198-1, HMAC-SHA-256 and wider, stay approved and stay deployed across the internet’s protocols throughout and after any documentation change.

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

Does the FIPS 198-1 standard survive quantum computers?

Yes. The HMAC that FIPS 198-1 specifies survives the quantum transition, and this is the calm corner of the whole quantum-cryptography story. HMAC is a symmetric construction over a hash function, so it rests on no factoring or discrete-logarithm problem, which means Shor’s algorithm, the quantum attack that actually breaks cryptography, has nothing to grab onto. The only quantum pressure it faces comes from Grover’s algorithm, and Grover weakens rather than breaks:

1. Forging a tag means searching for the key, and Grover only square-roots that search. Grover reduces the cost of brute-forcing an n-bit key from 2 to the n down to about 2 to the n/2. A 256-bit HMAC key drops to roughly 2 to the 128 of effective work, which stays astronomically out of reach.
2. The fix, where more margin is wanted, is a longer key, not a new algorithm. 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 preferring HMAC-SHA-256 or wider. There is no post-quantum HMAC to migrate to.

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 through the transition. The numbers and the deeper reasoning live in the HMAC note.

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

How does FIPS 198-1 relate to the other NIST cryptography standards?

FIPS 198-1 is one tile in a small mosaic of NIST cryptographic standards, and it makes the most sense once you see which job each neighbor does. FIPS 198-1 specifies the keyed message-authentication mechanism; the hashes it runs on, the guidance for using it, and the public-key counterpart it contrasts with all live in separate documents:

Standard	What it covers	Relationship to FIPS 198-1
FIPS 180-4	Defines the SHA-1 and SHA-2 hash functions	Supplies the hashes HMAC is built on
FIPS 202	Defines the SHA-3 family (Keccak sponge)	Also supplies approved hashes for HMAC
SP 800-107	Hash-strength, key-length, and truncation guidance	The companion for using FIPS 198-1 correctly
FIPS 186-5	The Digital Signature Standard (RSA, ECDSA, EdDSA)	The public-key authentication counterpart, and the quantum-vulnerable one

The cleanest way to hold the relationship is that FIPS 198-1 and FIPS 186-5 are the two ways NIST standardizes “prove this message is authentic.” FIPS 198-1 does it symmetrically with a shared key, which is fast and quantum-safe but cannot prove which key holder signed. FIPS 186-5 does it with public-key signatures, which prove a single signer and provide non-repudiation but fall to Shor’s algorithm. That split is exactly why the quantum migration is a public-key job, and why the FIPS 198-1 side of the house needs no replacement.

Source: NIST, “Digital Signature Standard (DSS),” FIPS 186-5, February 2023, FIPS 186-5.

Common misconceptions

1. “FIPS 198-1 defines the SHA hash functions.” It does not. FIPS 198-1 specifies how to key a hash into a MAC; the hash functions themselves are defined in FIPS 180-4 (SHA-1 and SHA-2) and FIPS 202 (SHA-3).
2. “FIPS 198-1 is outdated because it’s from 2008.” It remains the current, final HMAC standard. NIST’s planned SP 800-224 consolidates it with SP 800-107, which is a documentation refresh rather than a break, and HMAC stays approved throughout.
3. “HMAC under FIPS 198-1 needs a post-quantum replacement.” It doesn’t. HMAC is symmetric, so only Grover’s algorithm applies, and a 256-bit key absorbs the square-root speedup with margin to spare.
4. “HMAC encrypts the message.” No. HMAC is a MAC, it proves integrity and authentication while leaving the message fully readable. Secrecy is a separate job handled by encryption.
5. “Any hash plus key I invent is FIPS 198-1 compliant.” Compliance means the specific nested HMAC construction over an approved hash. A homemade keyed hash like H(K || message) is not HMAC and is vulnerable to a length-extension attack the standard’s structure exists to prevent.
6. “FIPS 198-1 tells me how to use HMAC inside TLS or a signature.” It defines the primitive only. How HMAC is wired into a protocol lives in that protocol’s own specification, and hash-usage rules live in SP 800-107.

Questions people ask

What does FIPS 198-1 actually specify? It specifies HMAC, the keyed-hash message authentication code, a mechanism that combines an approved cryptographic hash function with a shared secret key to produce an authentication tag. It fixes the exact construction (key preparation, the inner and outer pads, the double hashing, and optional truncation) so that any correct implementation is interoperable.

Is HMAC FIPS-approved? Yes. HMAC is approved by NIST in FIPS 198-1 when it’s built on an approved iterative hash function, which today means the SHA-2 and SHA-3 families. HMAC-SHA-256 and wider are approved and heavily deployed.

Which hash should I use with HMAC under FIPS 198-1? SHA-256 is the sensible default, moving up to SHA-384 or SHA-512 where you want extra long-term margin. Avoid HMAC-MD5 entirely, and de-emphasize HMAC-SHA-1 in new designs even though HMAC held up longer than plain SHA-1.

Does FIPS 198-1 allow truncating the tag? Yes. The standard permits keeping only the leftmost t bytes of the HMAC output, which some protocols do to save space (IPsec’s HMAC-SHA-256-128 keeps 128 bits). The guidance is to keep enough of the tag that blind forgery stays infeasible, with the detailed minimums in SP 800-107.

Is FIPS 198-1 still current, or was it withdrawn? It’s current. FIPS 198-1 has been the final HMAC standard since July 2008. NIST plans to fold its content, together with SP 800-107, into a new SP 800-224, but that consolidation does not withdraw HMAC or change the algorithm.

Do I need FIPS validation to use HMAC? Anyone can implement and use HMAC, since the algorithm is public. Federal procurement is where validation enters: a federal system generally needs the cryptographic module implementing HMAC to be validated through NIST’s module-validation program, which is a property of the module, not permission to use the math.

Does FIPS 198-1 need to change for post-quantum security? No. HMAC is symmetric and survives the quantum transition, so the standard needs no quantum-driven revision. The post-quantum migration effort belongs on the public-key standards, the signatures in FIPS 186-5 and the key exchange those protocols use.

What’s the difference between FIPS 198-1 and FIPS 180-4? FIPS 180-4 defines the SHA hash functions themselves, the raw fingerprinting algorithms. FIPS 198-1 defines HMAC, which keys one of those hashes into a message authentication code. FIPS 198-1 depends on FIPS 180-4, so HMAC-SHA-256 uses the SHA-256 that FIPS 180-4 specifies.

---

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.