HMAC Generator — RFC 2104 Keyed Hash-Based Message Authentication Guide
Generate HMAC-SHA1, HMAC-SHA256, and HMAC-SHA512 authentication codes in your browser per RFC 2104 and FIPS 198-1.
01. HMAC: RFC 2104 Keyed Hash Authentication
HMAC (Hash-based Message Authentication Code), defined in RFC 2104 and standardized in NIST FIPS 198-1, provides both data integrity and authentication using a cryptographic hash function and a shared secret key. Unlike a plain hash, an HMAC verifies both message integrity and sender identity.
The HMAC construction is: HMAC(K, m) = H((K XOR opad) concatenated with H((K XOR ipad) concatenated with m)), where H is the hash function and K is the key padded to block size. This double-pass construction is secure even if the underlying hash has weaknesses against length-extension attacks.
HMAC is used throughout web security: JWT signatures (HMAC-SHA256 = "alg: HS256"), API request signing (AWS Signature Version 4, Stripe webhook verification), webhook payload validation, and OAuth 1.0a request signing.
- RFC 2104 HMAC: Keyed MAC using nested hash — secure against length-extension attacks.
- FIPS 198-1: NIST standardization of HMAC with SHA-1, SHA-256, SHA-384, SHA-512.
- JWT HS256: HMAC-SHA256 signature — key minimum 256 bits per RFC 7518 §3.2.
- AWS Signature V4: Multi-step HMAC-SHA256 key derivation for request signing.
- Webhook verification: GitHub, Stripe, Shopify use HMAC-SHA256 for payload integrity.
02. HMAC Key Length & Timing-Safe Comparison
RFC 2104 recommends HMAC keys be at least as long as the hash output (32 bytes for HMAC-SHA256, 64 bytes for HMAC-SHA512). Keys shorter than the hash output reduce security.
When comparing HMAC values, a timing-safe comparison must be used. Standard string equality short-circuits on the first mismatched character, leaking timing information that allows byte-by-byte forgery. Use crypto.timingSafeEqual() (Node.js) or hmac.compare_digest() (Python) for all HMAC comparisons.
- Min key length: 32 bytes for HMAC-SHA256, 64 bytes for HMAC-SHA512 per RFC 2104.
- Timing-safe comparison: Never use === for HMAC — use crypto.timingSafeEqual().
- Length-extension immunity: HMAC double-pass prevents length-extension attacks.
- Key rotation: Rotate HMAC signing keys on schedule with key ID metadata.
Frequently Asked Questions (FAQ)
What is the difference between HMAC and a plain hash?
A plain hash verifies data integrity only. An HMAC (RFC 2104) adds a secret key — only parties knowing the key can generate or verify the code, providing authentication in addition to integrity.
Why must I use timing-safe comparison for HMAC verification?
Standard string comparison short-circuits on the first mismatched byte, allowing timing side-channel attacks. crypto.timingSafeEqual() always takes the same time regardless of mismatch position.
Is my confidential data uploaded to external servers when using HMAC Keyed-Hash Signature Generator?
No. Core processing in HMAC Keyed-Hash Signature Generator executes in volatile browser memory without server uploads. Inputs to local tools are not logged on remote servers; optional cloud-assisted features require user consent.
Can I use HMAC Keyed-Hash Signature Generator offline without an active internet connection?
Offline use requires the page and its tool assets to finish caching first. Core transformations can then run locally; optional AI and contact delivery require internet.
Is HMAC Keyed-Hash Signature Generator free to use with any rate limits or paywalls?
Core tools are free to use without an account. Device memory and tool-specific safety limits apply. Optional AI and online contact services have usage limits.