CipherLayer
Home / Tools / HMAC Builder

HMAC Builder

HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 message authentication. Visualize the inner/outer key padding (ipad/opad), demonstrate tamper detection, and truncate the output to a chosen length.

ipad/opad viz Tamper demo Truncate option Web Crypto API RFC 2104

Inputs

Recommended: 32 random bytes (64 hex chars). Shorter keys are zero-padded; longer keys are pre-hashed.

Output

// HMAC output will appear here HMAC is a keyed hash. Same key + same message = same HMAC. Different key or different message = different HMAC, with overwhelming probability.
Algorithm
—
HMAC length
—
Time
—
HMAC ≠ encryption. HMAC produces a tag, not ciphertext. The receiver can verify the tag (you have the right key and untampered message) but cannot "decrypt" anything because there is nothing encrypted. For actual encryption with authentication, use our AES-GCM tool.

Why this tool, and why this version

An HMAC answers one question: does this message come from someone who knows the key, and has it been modified in transit? The "tamper detection" tab shows this directly — same key, slightly different message, completely different tag. That's the property you rely on for JWT signing, API request signing, and message authentication in TLS.

The ipad/opad tab exposes what most HMAC libraries hide: HMAC = hash((key ⊕ opad) || hash((key ⊕ ipad) || message)). Two nested hash invocations with the key XOR'd against two different constants. The inner hash produces a fixed-size intermediate, the outer hash produces the final tag. This double-hash construction defeats length-extension attacks that would break naive hash(key || message).

The truncate option lets you cut the HMAC to a shorter length. RFC 2104 allows truncation for specific scenarios (e.g., RFID tags where every byte is expensive), but warns that halving the tag roughly squares the forgery probability. We display the warning inline so you don't accidentally weaken your security.

All HMAC computation goes through Web Crypto's crypto.subtle.sign('HMAC', ...), which delegates to the OS-native implementation. This is the same primitive used by AWS Signature V4, JWT, and OAuth.

Who this is for

Backend engineers building APIs

You sign API requests with HMAC-SHA256 (or HMAC-SHA512 for FIPS). This tool lets you reproduce the server-side calculation when debugging mismatches. Paste the key and request body, get the expected signature, compare against what your client sent.

Security researchers analyzing protocols

You encounter a protocol that uses HMAC with non-standard parameters (truncated, wrong hash, custom encoding). This tool lets you replicate the exact construction to verify it's implemented as documented.

Students learning MACs

HMAC is the textbook example of a secure Message Authentication Code. Watching the ipad/opad bytes appear makes the construction concrete in a way that a paper cannot.

Frequently asked questions

Why HMAC and not just hash(key || message)? ▶
The naive construction hash(key || message) is vulnerable to length-extension attacks. If the attacker knows hash(key || message) and the length of key, they can compute hash(key || message || extra) without knowing the key. This works against SHA-256, SHA-512, and other Merkle–Damgård hashes. HMAC's double-hash with ipad/opad defeats this — the attacker can't compute the intermediate state because the outer hash absorbs it. The exact security proof is in RFC 2104.
What's the difference between HMAC and a KDF? ▶
HMAC is a Message Authentication Code: it takes a message and a key, produces a tag, and the tag's purpose is verification. A KDF (Key Derivation Function) takes secret material and produces one or more keys as output; the output's purpose is to be used as input to other crypto. Functionally similar — both are key-in/hash-out — but the threat models differ. Use PBKDF2 for password-based KDF; use HKDF for high-entropy IKM expansion; use HMAC for message tags.
Why is my HMAC different from another tool's output? ▶
Three common causes: (1) Key encoding — your key must be the raw bytes, not the ASCII string. "Password" as a string is 8 bytes (70 61 73 73 77 6f 72 64), but if the other tool interpreted it as UTF-8 it's the same. If it treated it as a hex string, you'd need 16 bytes from "50617373776f7264" (16 hex chars). (2) Output encoding — hex vs base64 vs raw bytes. (3) Truncation. Check all three before assuming a bug.
Is it safe to truncate HMAC? ▶
For most uses, no. RFC 2104 says "truncated output … is intended for applications where the tag length is constrained, but otherwise the security of the protocol should not depend on the full HMAC output." Halving the tag from 32 bytes to 16 bytes squares the forgery probability (from 2⁻¹²⁸ to 2⁻⁶⁴, approximately). 2⁻⁶⁴ is still infeasible in practice, but the margin shrinks. Use full-length tags unless you have a specific size constraint.
Can I use HMAC for password storage? ▶
No. HMAC is fast. An attacker can compute billions per second on a GPU. Use a slow KDF with salt: PBKDF2 at 600,000+ iterations, bcrypt, scrypt, or Argon2id. PBKDF2-HMAC-SHA256 is internally built from HMAC, but the iteration count makes it expensive to attack.
What happens if my key is shorter or longer than the block size? ▶
Per RFC 2104: if key length > block size (64B for SHA-256), the key is replaced with hash(key). If key length < block size, the key is zero-padded to block size. Our tool follows this exactly. You can see the zero-padding on the ipad/opad tab by entering a short key — the right-hand bytes of ipad-key and opad-key will be the original key XOR'd with the constant, and the remaining bytes will be the constant alone (since 0 XOR 0x36 = 0x36, 0 XOR 0x5C = 0x5C).
Is HMAC vulnerable to quantum computers? ▶
Grover's algorithm gives a quadratic speedup against preimage search, reducing HMAC-SHA256's security from 2²⁵⁶ to 2¹²⁸. That's still infeasible. The bigger quantum threat is to public-key crypto (RSA, ECDSA, ECDH). For symmetric crypto, doubling the key size compensates. SHA-256-based HMAC remains safe in a post-quantum world.

Limitations you should know