HMAC 生成器
加密使用 Web Crypto 计算 HMAC-SHA-1/256/384/512 签名。输出 Hex 或 Base64,全程在浏览器内完成。
不获取远程 URL;请直接粘贴你的 JSON。
本页内容
什么是 HMAC?#
HMAC 的全称是 基于哈希的消息认证码。普通的哈希(比如 SHA-256)回答的是”这段字节流被改过没有”;HMAC 回答的是一个更强的问题——“这段字节流被改过没有,而且它是不是由那个跟我共享密钥的人发出来的?“。只要消息要走一段你并不完全信任的链路——Webhook 回调、签名 URL、API 请求签名、服务间令牌——HMAC 就派得上用场。
原理上,HMAC 把一个密钥按固定方式(两轮哈希,中间夹填充)混进哈希函数,这样得到的摘要没有密钥就伪造不出来。输出长度等于底层哈希的长度:SHA-1 是 20 字节、SHA-256 是 32 字节、SHA-384 是 48 字节、SHA-512 是 64 字节。
本页用浏览器内的 Web Crypto API 来算 HMAC。你选好哈希算法,贴上消息和密钥,就能得到十六进制或 base64 形式的摘要。
怎么使用#
- 在 消息 框里输入或粘贴要认证的内容。这就是对方在他们那边要参与哈希的字节。
- 填入 密钥。这个输入框默认是遮住的,点右边那个眼睛按钮可以在输入时临时显示。密钥和消息都按 UTF-8 编码。
- 选择 算法:
- SHA-1 —— 160 位。速度快,但只适合兼容老式 HMAC 场景(某些早期签名流程还在用)。数字签名绝对不要再用 SHA-1。
- SHA-256 —— 256 位。当今的默认选择,绝大多数 Webhook 签名(Stripe、GitHub、Slack 风格的流程)用的都是 HMAC-SHA-256。
- SHA-384 / SHA-512 —— 摘要更长,抗碰撞余量更大,速度略慢。一般是接收端明确要求时才选。
- 选择 输出 编码:十六进制(常见的
X-Signature风格头用这种)或 base64(摘要要塞进 JSON 或 token 时常用)。 - 点 生成。右侧立刻出现摘要;状态栏会显示算法和字节数,作为长度自检。点 复制 取走。
主要特性#
- 基于 Web Crypto。 直接调用浏览器原生
crypto.subtle,跟生产代码用的是同一个原语——不是 JavaScript 重新实现一遍。 - 长度自检。 每个摘要都会跟该算法应有的字节长度对一遍,被截断或被篡改的结果没法悄悄溜过去。
- 十六进制 / base64 一键切换。 不用重新输入。
- 密钥不出本机。 密钥输入框按密码字段渲染,从不上传——本站没有后端。
- 识别安全上下文。 万一页面被放在了普通 HTTP 下加载,
crypto.subtle是不可用的,工具会直接报这个错,而不是给一个错的答案。
实例演示#
RFC 4231 里有一对经典的测试向量,密钥 Jefe、消息 what do ya want for nothing?。本页算法选 SHA-256、输出选 十六进制,得到的摘要是:
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843
同样的输入切到 SHA-512,摘要长度翻倍:
164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737
你现在就能在这里复现:点 示例,再点 生成。本工具自带的单元测试就是用这一对来验证正确性的——要是哪天算出来的结果不一样,说明这一页被人动过手脚。
常见问题#
SHA-256 还是 SHA-512,到底选哪个?#
做 HMAC 的话,SHA-256 是务实之选:主流 Webhook 都用它、足够快、256 位的摘要早已远超暴力破解的范畴。只有两种情况考虑 SHA-512——(a) 接收端明确要求,(b) 你在从零设计一个新协议,想要多一点抗碰撞余量,并不在意那一点点速度损失。SHA-1 尽量别碰,除非要兼容一个非它不可的老系统。
HMAC 等于把消息加密了吗?#
不等于。HMAC 只做认证——它证明消息没被改动、并且来自持有密钥的人。消息本身仍然是明文。如果同时还想保密,要么把 HMAC 配合某个加密方案一起用,要么直接上带认证的加密模式(比如 AES-GCM)。
能不能从摘要反推出密钥?#
不能。摘要同时是消息和密钥的单向函数,从输出反推密钥在计算上不可行。但要注意:太短或太容易猜的密钥,对方完全可以离线暴力试出来——所以密钥至少要有 128 位真实熵,别用一个人想出来的口令当密钥。
对方说签名对不上,先查什么?#
十次里有九次是消息的字节表示没对齐:末尾多了换行、URL 编码还是原始 body 没分清、JSON 的空白不一样、字段顺序不同。在查任何别的东西之前,先把你签过的那串字节和对方哈希的那串字节一个字符一个字符地比一遍。