HMAC 与哈希计算器
选择要计算的内容——使用密钥的 HMAC、普通摘要或常量时间比较——然后输入:结果随输入实时更新,以十六进制、base64 和 base64url 显示,并附有说明,解释两个系统为何会得出不同的结果。
100% 本地处理——密钥、消息和结果都留在你的浏览器中,不会发送到任何服务器
HMAC
示例:RFC 4231 §4.3 的测试用例 2——使用密钥“Jefe”的 HMAC-SHA-256,已与公布的 MAC 核对。
Hashes: fingerprints of data
A cryptographic hash function maps any input to a fixed-size digest: 32 bytes for SHA-256, 64 for SHA-512. Change one bit of the input and about half the output bits change. The SHA-2 family is specified in FIPS 180-4, SHA-3 — a different design on the Keccak permutation — in FIPS 202. The calculator computes all of them at once, plus SHA-1 and MD5, which survive in checksums and old protocols: collisions for MD5 can be produced in seconds, and the first SHA-1 collision was published in 2017. Use them to compare with existing values, never to protect anything new.
A digest proves nothing about who produced the data — anyone can recompute it. That is what a key is for.
HMAC: a hash with a key
HMAC (RFC 2104, FIPS 198-1) turns a hash into a message authentication code. Only someone who holds the key can compute the MAC of a message, and only someone who holds it can check one:
HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m))
The key is padded to the hash's block size (64 bytes for SHA-256, 128 for SHA-512) and mixed in twice, with two different constants. The obvious shortcut — SHA-256(key ‖ message) — is broken for SHA-2: a hash built on the Merkle–Damgård construction lets anyone who knows one digest compute the digest of the message with more data appended, without the key. That is the length-extension attack, and the nested structure of HMAC is what defeats it.
A key longer than the block is first replaced by its hash (RFC 2104 §2), so extra length adds nothing. A key shorter than the output is discouraged (§3); for JWTs, RFC 7518 §3.2 requires an HS256 key of at least 32 bytes. The calculator says when your key is outside those bounds.
HMAC in JWTs
A JWT signed with HS256, HS384 or HS512 carries exactly this MAC: HMAC with SHA-256, SHA-384 or SHA-512 over the ASCII bytes of base64url(header).base64url(payload), base64url-encoded as the third part of the token. Paste the first two parts of a token as the message and the secret as the key, and the HMAC (base64url) output is the signature the token should end with. If it is not, the token was signed with another secret or changed. To build and sign a whole token instead, use the JWT signer; to find out whether the secret is one of the thousands that leaked into tutorials and code, the JWT secret checker.
Why two systems disagree
HMAC itself is deterministic: identical bytes in, identical MAC out. When two systems disagree, the bytes were different. The usual culprits, which the calculator points out as it sees them:
- Encoding of the key or the message. The secret
c2VjcmV0used as text is eight bytes; decoded from base64 it is six. Choose how each input is written: text (UTF-8), hex, base64 or base64url. - A trailing newline.
echo "message" | openssl dgst -sha256 -hmac keyhashes the line break too;echo -ndoes not. - Windows line breaks (CR LF) against Unix ones (LF), and spaces at the ends of the text.
- Unicode normalization. "é" can be one code point or two, and they are different bytes.
- Output encoding. The same MAC is a 64-character hex string, a 44-character base64 string or a 43-character base64url string.
Checking a MAC: constant time
Comparing a received MAC with the computed one byte by byte and stopping at the first difference leaks, through timing, how many leading bytes were right — enough, over many requests, to forge a MAC one byte at a time. The comparison must take the same time wherever the first difference is. The Expected MAC field and the Compare two values mode compare that way, independent of how each value is written. A shorter expected value is checked as a truncated MAC, as RFC 2104 §5 allows, with a warning when it is shorter than half the output or 80 bits.
Everything stays here
The calculator runs on the audited @noble/hashes in your browser and makes no network request. A share link carries the algorithm, the message and the expected MAC — never the key, and never the two values of a comparison. The examples are published test vectors: RFC 4231 §4.3 for HMAC-SHA-256 and a NIST CAVP vector for SHA-256, and the page shows that it reproduces them.