HMAC 生成器

关于此工具

HMAC 能证明什么

HMAC（RFC 2104）通过哈希函数把消息与密钥混合，输出一个简短的认证标签（tag）。持有同一密钥的人可以重新算出这个标签。如果两个标签相同，就说明消息在传输中没有被改动（完整性），而且是由知道密钥的人生成的（真实性）。

普通哈希做不到这一点，因为篡改消息的人同样可以重新计算它的哈希。HMAC 不会隐藏消息，所以它不是加密。而且由于双方持有相同的密钥，它无法证明消息是双方中的哪一方写的，这需要使用私钥的数字签名。

Webhook 签名

最常遇到 HMAC 的地方是 Webhook。提供方用与你共享的密钥对请求体签名，并把标签放在请求头中发送；你的服务器在信任该请求之前，先算出同样的 HMAC。GitHub 以 hex 形式发送 X-Hub-Signature-256: sha256=…，Shopify 以 Base64 形式发送 X-Shopify-Hmac-SHA256，Stripe 则对时间戳、一个点号和请求体签名，再把结果以 v1=… 的形式放在 Stripe-Signature 中发送。

要对请求体到达时的原始字节原样签名。如果框架先解析了 JSON，你又重新序列化，空白和键的顺序就会改变，HMAC 也就对不上了。如果这里的签名验证失败，先检查密钥编码（文本、hex 还是 Base64），再检查消息末尾是否有换行。

为什么服务器要用常量时间比较

普通的字符串比较在遇到第一个不同的字符时就会停止。在服务器上，这会让伪造签名的前几个字节错误时响应稍快一些、正确时稍慢一些，能测量出这一差异的攻击者就可以逐字节还原出有效的标签。常量时间比较无论结果如何都会读完每个字节。请使用你所用平台提供的函数：Node.js 中的 crypto.timingSafeEqual、Go 中的 hmac.Equal、Python 中的 hmac.compare_digest、PHP 中的 hash_equals。

本页的比对框也是这样工作的：它把两个值都解码为字节并全部读完。在已经同时持有两个值的浏览器标签页里，并没有需要隐藏的时间差，所以在这里它只用来告诉你，你自己的代码是否算出了正确的标签。

运行方式

标签由 Go 的 crypto/hmac 包计算，编译为 WebAssembly 后在浏览器的后台线程中运行。消息按 UTF-8 处理，不添加也不删减任何内容。只有一点会变化：浏览器的文本框会把每个换行都保存为单个换行符（LF），因此以 CRLF 换行的消息在这里会按 LF 签名。密钥按 UTF-8 文本处理，或在你指定时从 hex 或 Base64 解码。两者都不会被发送到任何地方。不过，生产环境的密钥最好还是不要放进网页：能用测试密钥时，就用测试密钥。