tigtools

HMAC 生成器

使用消息和密钥计算消息认证码（HMAC），或验证收到的签名。密钥和消息仅在浏览器中处理。

在浏览器中运行 无需注册

密钥和消息仅在当前浏览器标签页中处理，不会发送到任何地方。不过，请避免在共享或不受信任的电脑上粘贴正在使用的生产密钥。
密钥格式

输入内容会按 UTF-8 原样签名。末尾的空格或换行都会改变结果。

输出格式

粘贴十六进制（大小写均可）或 Base64 格式的签名，与上方结果进行比较。

使用方法

  1. 输入密钥，并选择密钥格式为纯文本还是十六进制字节。
  2. 粘贴要处理的消息，例如收到的 webhook 请求正文，内容须与收到时完全一致。
  3. 选择服务使用的算法和输出编码；输入时会自动更新 HMAC。
  4. 如需验证签名，请将其粘贴到验证框中，并查看是否显示“匹配”。

工作原理

HMAC（RFC 2104）将密钥与哈希函数结合，生成只有持有该密钥的人才能创建的签名。Webhook 和签名 API 请求等服务会随每条消息发送 HMAC，以便接收方检查消息是否真实且未被篡改。

此工具使用浏览器的 Web Crypto API（crypto.subtle.importKey 和 sign），并通过 RFC 4231 和 RFC 2202 测试向量进行校验。文本格式的密钥和消息会以 UTF-8 编码。十六进制密钥会解码为原始字节；空格、冒号和开头的 0x 会被忽略。HMAC-SHA-256 是最常见的选择；HMAC-SHA-1 作为 MAC 仍被认为是安全的，但主要用于较旧的 API。

如果签名不匹配，请检查以下常见差异：消息的确切字节内容（许多 webhook 提供方会对原始请求正文签名，而非重新格式化后的 JSON）、提供方添加到签名字符串中的时间戳或前缀、密钥是按文本使用还是需要先从十六进制或 Base64 解码，以及预期签名使用的是十六进制还是 Base64、是否带有“sha256=”之类的前缀（比对前应将其移除）。

示例

RFC 4231 测试用例

密钥为“Jefe”（文本格式），消息为“what do ya want for nothing?”，使用 HMAC-SHA-256 得到 5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843。点击“试用示例”即可载入。

验证 webhook 签名

提供方会在每个请求中发送 X-Signature: sha256=… 标头。将原始请求正文粘贴为消息，将 webhook 密钥作为密钥，选择 HMAC-SHA-256 和十六进制，然后将“sha256=”之后的值粘贴到验证框中。

十六进制编码的密钥

有些系统会提供 0b0b0b… 这样的十六进制密钥。请将密钥格式设为十六进制，这样工具就会使用解码后的字节进行签名；若将相同字符串当作文本处理，结果会完全不同。

常见问题

HMAC 与普通哈希有什么区别？

任何人都可以计算消息的普通哈希，例如 SHA-256。HMAC 还依赖密钥，因此只有持有密钥的人才能生成或验证 HMAC。这可以证明消息来自密钥持有者，且未被篡改。

为什么我的 HMAC 与服务器上的不匹配？

输入字节几乎总会存在差异，例如换行符、空白字符、JSON 键的顺序、字符编码，或本应从十六进制或 Base64 解码的密钥。此外，请确认使用相同的编码格式（十六进制或 Base64），并移除“sha256=”之类的前缀。

我的密钥会发送到其他地方吗？

不会。密钥和消息仅由此浏览器标签页中的 Web Crypto API 使用，不会上传、存储或纳入分析数据。

HMAC-SHA-1 仍安全吗？

SHA-1 碰撞不会直接破坏 HMAC-SHA-1，它目前仍因兼容性需要而被接受。新系统请使用 HMAC-SHA-256 或更强的算法。

隐私

密钥、消息和结果仅存在于当前浏览器标签页中。数据不会上传、存储或发送到分析服务；我们只会记录一条匿名的工具使用事件。