— — 请输入密钥和消息 — —— — 请输入密钥和消息 — —— — 请输入密钥和消息 — —— — 请输入密钥和消息 — —关于 HMAC 生成器
HMAC 是把消息和一把密钥一起送入哈希函数得到的认证码，用来同时验证数据完整性和来源身份，广泛出现在 Webhook 验签、API 请求签名和 JWT 的 HS256 算法里。本工具调用浏览器原生的 Web Crypto API，在本地用你输入的密钥对消息计算 HMAC，支持 SHA-1/SHA-256/SHA-384/SHA-512，可选 Hex 或 Base64 输出。密钥和消息都只在你的设备内存里运算，不会发往任何服务器，复制结果即可与服务端签名逐字节比对。密钥和消息都只在设备内存里运算，不会发往任何服务器，是接口安全的本地校验点。例如用密钥 secret 对消息 hello 计算 HMAC-SHA256，得到 64 位十六进制签名，可直接用于 API 请求签名校验。
需要在「双方共享一个密钥」的前提下证明消息未被篡改、且确实来自持有密钥的一方，就要用到消息认证码。它与签名不同：签名用私钥签发、公钥验证，可以多方验证且不可否认；认证码用同一密钥计算与验证，因此只能由共享密钥的双方使用，好处是速度快、实现简单。 原理上，认证码不是「把密钥拼在消息前面再取哈希」这么简单。把密钥直接拼接存在长度扩展攻击的风险：攻击者可以在不知道密钥的情况下，基于已有摘要推算出「原消息加若干字节」的合法摘要。正规构造会把密钥经过两次包装再加入散列，从而抵御这类攻击，因此必须使用标准实现而不是自行拼接。 使用要点：密钥必须是随机生成的高熵数据，不能使用口令或其他可猜测的字符串；比较摘要时必须使用恒定时间比较，否则逐字节比较会通过响应时间泄露匹配前缀，理论上可以从远程逐步猜出正确摘要。参与计算的内容要覆盖所有需要保护的部分，包括方法、路径、时间戳与请求体摘要，只对部分内容计算会给篡改留下空隙；时间戳纳入计算并设定容忍窗口，可以顺便缓解重放。 边界与限制：认证码只保证完整性与来源，不保证机密性，消息内容仍是明文，需要保密时应配合加密。它也不解决「谁发的」这个多方场景问题，涉及多方验证时应改用非对称签名。此外实现细节上有不少坑：密钥长度超过散列分组长度时会被先压缩，理解这一点对排查「两端不一致」很关键；编码方式也要统一，一端用十六进制另一端用文本输出会得到不同结果。 数据与隐私：认证码用于保护敏感接口，密钥一旦泄露等同于签名能力被夺走。本工具在浏览器内计算，不上传密钥与消息；处理生产密钥时建议离线使用，并定期轮换密钥以缩小泄露影响面。
误用一是自行拼接密钥与消息再取哈希，这种构造存在长度扩展风险，攻击者可在不知道密钥时推算出「原消息加若干字节」的合法摘要，必须使用标准实现。二是用普通的逐字节比较校验摘要，比较过程会通过响应时间泄露匹配前缀，理论上可被远程逐步猜出正确值，因此必须使用恒定时间比较。
实现原理
认证码把密钥经过两次包装后与消息一起送入散列函数，因此它不是「哈希加盐」，而是能抵御长度扩展攻击的构造。简化理解：内层先用密钥处理消息并取散列，外层再用密钥处理该散列。校验必须用恒定时间比较，否则逐字节比较会通过响应时间泄露匹配前缀。
密钥 key，消息 The quick brown fox固定输出（如 hex 摘要）；把消息改成 The quick brown foX 会得到完全不同的值（雪崩效应）使用方法
- 打开「HMAC 生成器」
- 输入待处理的内容并设置参数
- 根据需要调整输出选项
- 点击「生成」按钮，结果实时显示
- 复制或导出结果
使用场景
- Webhook 验签 — 用平台给的 Secret 重算 HMAC-SHA256，和请求头里的签名比对，确认回调真伪。
- API 请求签名 — 按厂商规则拼接待签字符串后生成 HMAC，作为接口鉴权头发送。
- 调试 JWT HS256 — 手动复现 header.payload 的 HMAC，排查 JWT 签名校验失败的原因。
- 比对算法实现 — 验证后端语言（如 Java、Python）算出的 HMAC 是否与标准一致。
- 生成幂等键签名 — 对订单号等参数做 HMAC，得到可复算又防篡改的校验值。
常见问题
HMAC 和直接 SHA-256 有什么区别？
普通哈希任何人都能算，无法证明来源；HMAC 引入只有双方知道的密钥，没有密钥就算不出正确结果，因此能验证消息确实出自持密钥的一方。
密钥应该用文本还是 Hex？
取决于服务端约定。多数 Webhook 用 UTF-8 文本密钥，但有些 API 要求把密钥按 Hex/Base64 解码成原始字节再参与运算，两种方式结果不同，务必匹配对端。
该选哪种哈希算法？
SHA-256 是当前默认推荐，兼顾安全与性能；SHA-1 仅用于兼容老系统，不建议新项目使用；需要更高安全裕度时选 SHA-384/512。
比较签名时要注意什么？
生产代码里应使用恒定时间比较（constant-time compare），避免通过响应耗时差异泄露信息；本工具仅用于人工核对，复制后请用安全方式校验。
输出大小写或编码不一致正常吗？
HMAC 原始结果是字节，Hex 大小写、是否 Base64 只是表现形式。先统一编码格式再比对，不要因为大小写差异误判为签名不符。
本地算出的签名和服务端验签结果不一致，怎么排查？
先确认密钥的字节表示：服务端若把密钥当作十六进制字符串解码后再参与计算，而本地把密钥文本直接当字节使用，两端结果必然不同。其次确认参与签名的内容是否逐字节一致，空格、换行与字段顺序的细微差异都会改变结果。最后确认输出编码是十六进制还是 Base64，这一点在日志里最容易看错。
把密钥直接拼在消息前面再取哈希，和这种算法有什么区别？
直接拼接存在长度扩展风险：攻击者可以在不知道密钥的情况下，基于已有摘要推算出「原消息加若干字节」的合法摘要。正规构造会把密钥经过两次包装后参与计算，从而抵御这类攻击。因此必须使用标准实现，自行拼接即使结果看起来正常，安全性也已经不成立。
HMAC 和普通哈希的区别是什么？
普通哈希谁都能算，HMAC 需要持有密钥才能算出相同结果——所以它能同时验证「完整性」和「来源」。API 签名（如 AWS、微信支付）都是 HMAC：服务端用同样的密钥重算并比对，密钥不匹配就拒绝。