HMAC Generator

The HMAC Generator creates Hash-based Message Authentication Codes — cryptographic signatures that prove a message came from someone who knows a shared secret, and that it has not been tampered with in transit. Supports HMAC-SHA256 (the modern standard, used by Stripe, Shopify, AWS, GitHub, Slack webhooks), HMAC-SHA512 (for higher security), HMAC-SHA1 (legacy, still common), and HMAC-MD5 (deprecated but available for legacy APIs). Input any message and a secret key, get the HMAC output in hex, Base64, or Base64URL format.

HMAC is the foundation of most modern API authentication and webhook verification. When a webhook delivers an event payload, the sender signs it with HMAC-SHA256 using a secret only you and they know; you verify the signature to ensure (1) the payload really came from them, and (2) it has not been modified. AWS Signature Version 4 uses nested HMACs. Slack, Stripe, GitHub, Shopify, Twilio, DocuSign — all use HMAC for webhook verification. This tool runs entirely in your browser using the Web Crypto API — your secret keys and messages stay on your device.

HMAC (Hash-based Message Authentication Code) is defined in RFC 2104 (1997) and updated in RFC 6234 (SHA-2 variants). Unlike a plain hash (which anyone can compute), HMAC requires a secret key — only someone with the key can produce a valid HMAC for a given message.

Algorithm:

``
HMAC(key, message) = H( (key XOR opad) || H( (key XOR ipad) || message ) )
``

Where:
- H = hash function (SHA-256, SHA-512, etc.)
- opad = outer pad (0x5c repeated)
- ipad = inner pad (0x36 repeated)
- || = concatenation

Essentially: hash the message with a modified key, then hash again with a different modified key. The double-hashing structure protects against length extension attacks.

Supported variants:

| Variant | Output size | Status | Use case |
|---|---|---|---|
| HMAC-SHA256 | 256 bits | Recommended | Stripe, Slack, most modern APIs |
| HMAC-SHA384 | 384 bits | Secure | AWS Signature V4 |
| HMAC-SHA512 | 512 bits | Highest security | High-security contexts |
| HMAC-SHA1 | 160 bits | Deprecated for security | Legacy (GitHub webhooks v1) |
| HMAC-MD5 | 128 bits | Broken | Legacy only, do not use for security |

Output encodings:

- Hexadecimal: most readable. SHA-256 = 64 hex chars.
- Base64: more compact. SHA-256 = 44 chars (with padding).
- Base64URL: URL-safe Base64 without padding. Used in JWT headers.

Common use cases in practice:

1. Webhook signature verification:

GitHub sends webhook with header X-Hub-Signature-256: sha256=<hmac>:
- Server receives request.
- Compute HMAC-SHA256 of request body using webhook secret.
- Compare with received signature (using constant-time comparison).
- If match: request is genuine; proceed.

2. API request signing (AWS Signature V4):

- Client computes HMAC chain: date, region, service, request.
- Sends signature in Authorization header.
- Server re-computes, verifies match.

3. Signed URLs (presigned S3 URLs):

- Server computes HMAC of URL + expiration + permissions.
- Returns URL with signature as query parameter.
- Bucket verifies signature before serving.

4. Session tokens (JWT HS256):

- JWT header.payload signed with HMAC-SHA256 using server secret.
- Server verifies signature on each request.

Secret key requirements:

- At least 256 bits (32 bytes) for HMAC-SHA256 — RFC 2104 recommends key length ≥ hash output size.
- Generated from CSPRNG, not a password.
- Stored securely (environment variable, secret manager).
- Rotated periodically.

Constant-time comparison:

Comparing HMAC values with == leaks timing information. Use constant-time comparison (crypto.timingSafeEqual in Node, hmac.compare_digest in Python) to prevent timing attacks. This is critical for webhook verification servers.

HMAC vs plain hash:

- Hash (SHA-256(message)): deterministic, no secret needed. Anyone can compute. Proves integrity (was it changed?) but not authenticity (who created it?).
- HMAC (HMAC-SHA256(key, message)): requires secret. Proves both integrity AND authenticity. Used for authentication.

HMAC vs Plain Hash (SHA-256): Plain hash requires no secret — anyone can compute SHA-256 of a message. HMAC requires a shared secret — only parties with the key can compute valid signatures. Use hash for integrity checks, HMAC for authentication.

HMAC vs Digital Signatures (RSA, ECDSA): HMAC is symmetric — same key signs and verifies. Digital signatures are asymmetric — private key signs, public key verifies. HMAC is faster; signatures enable verification by anyone without sharing the key. Use HMAC for internal APIs, signatures for public-facing auth.

HMAC-SHA256 vs SHA-256 with prepended key: HMAC is resistant to length-extension attacks (a vulnerability where you extend a hash without knowing the key). Raw hash with key prepended (SHA256(key + message)) can be extended. Always use HMAC construct, not ad-hoc combinations.

HMAC vs CMAC: HMAC uses a hash function; CMAC uses a block cipher (AES). CMAC is used in some embedded systems. HMAC is more widespread on the web.

HMAC vs JWT HS256: JWT HS256 uses HMAC-SHA256 under the hood. Same cryptography, different encoding. JWT is a structured token format; raw HMAC is just a signature.

HMAC vs AWS Signature V4: AWS V4 uses HMAC chained multiple times (date_key -> region_key -> service_key -> signing_key). More complex but provides forward secrecy — compromising one step limits damage.