HMAC / HKDF Online Tool - HMAC-SHA256 / HS256 & Key Derivation

1. Generate an HMAC signature

Sender and receiver compute independently with the same key and algorithm; equality passes. Webhooks typically deliver it in an X-Signature-style header.

1. Set mode to HMAC and enter the message body (e.g. the raw request payload).
2. Enter the shared secret key.
3. Pick the hash (SHA-256 is the mainstream choice) and generate the hex signature.

2. Derive purpose keys with HKDF

1. Switch mode to HKDF; enter IKM (already high-entropy material such as a DH/session seed).
2. Optionally set salt (context) and info (purpose label, e.g. client-write-key).
3. Choose the OKM length in bytes; compare PRK (Extract) and OKM (Expand) in the result panel.

• Prefer a non-empty info — it is the domain-separation label that keeps purpose keys from colliding semantically.
• Switch input encoding to Hex when checking RFC 5869 appendix vectors.
• Stretch passwords with PBKDF2/argon2 (AES tool passphrase path), not HKDF.

3. Why HMAC instead of hash(secret+msg)

Naive concatenation, hash(secret + message), carries a structural flaw — the length-extension attack: the SHA-2 family is Merkle-Damgård based, so knowing hash(secret+msg) and the message length lets an attacker forge the valid value of hash(secret+msg+suffix) without the key, appending arbitrary suffixes. HMAC is structurally immune via nested double hashing (inner/outer pads). Every signing specification mandates HMAC over naive concatenation not as convention but as cryptographic necessity.

4. Signature comparison must be timing-safe

• Plain string equality returns early at the first differing byte, letting attackers brute-force signatures byte-by-byte from response-time differences.
• Verify server-side with constant-time comparison (crypto.timingSafeEqual in Node, or your language equivalent) — never == or ===.
• The raw body must be hashed byte-exactly: gateway field reordering or stray whitespace breaks signatures — the number-one cause of integration mismatches.

5. Timestamps and nonces against replay

1. Include a timestamp in the signed message (e.g. HMAC over timestamp + body).
2. Server-side, reject anything outside a ±5-minute window.
3. For higher assurance add a nonce: a one-time random value, with the server remembering used nonces to reject replays.

6. Output format, key length, and HKDF boundaries

• HMAC on this page defaults to lowercase hex; if the peer wants Base64 or a prefixed form (sha256=…), convert after copy — do not assume the wire format equals the raw digest.
• Prefer HMAC keys at least as long as the hash output (32 bytes for SHA-256); shorter keys are padded internally but gain no entropy.
• HKDF IKM must already be high-entropy; passwords, birthdays, and SMS codes are not IKM — stretch those with PBKDF2/argon2.
• Do not reuse one key across “sign” and “encrypt”; HKDF’s info label exists for purpose separation.

7. Webhook triage: fixed order when signatures disagree

First lock the exact bytes under the signature: raw body, re-serialized JSON, or a timestamp prefix — any mismatch fails everything. Next confirm algorithm and output encoding (hex / base64 / base64url). Only then check whether the secret was copied from the wrong environment. Finally implement verification with constant-time compare server-side. Use this page to reproduce the expected signature in-browser with the same body and a test secret — never paste production secrets here.