跳到正文
BCBinary Code Translator
菜单

密码学工具

HMAC SHA-256/384/512 生成器

使用浏览器 Web Crypto 对 UTF-8 密钥和数据生成 HMAC SHA-256、SHA-384 或 SHA-512,并输出 Hex 或 Base64。

密钥只用于当前 Web Crypto 运算,不写日志、不存浏览器存储,也不发送到外部服务。

本工具不会持久化密钥。不要在普通浏览器会话中使用真实生产密钥。

如何生成 HMAC

按协议原样输入共享密钥和消息,选择算法与输出编码后生成。两个字段都按 UTF-8 编码;一个空格、换行或编码差异都会改变认证码。

  1. 输入密钥。只有协议明确规定 UTF-8 文本密钥时才直接粘贴;Hex 或 Base64 往往表示原始字节,需要先解码。
  2. 输入完全一致的数据,包括换行、分隔符、时间戳和协议规定的 JSON 规范化形式。
  3. 选择 SHA-256、SHA-384 或 SHA-512,以及期望的 Hex 或 Base64。
  4. 生成并按协议验证完整结果,结束后清空密钥和剪贴板。

案例与预期行为

输入 输出 说明
密钥 Jefe 数据 what do ya want for nothing? HMAC-SHA-256 5bdcc146bf60754e6a042426089575c75… RFC 4231 测试用例 2。
密钥 secret 数据 message 确定性 HMAC 相同密钥、数据、算法和编码总是相同。
密钥 secret 数据 Message 不同 HMAC 大小写改变 UTF-8 字节。
密钥 密钥 数据 你好 UTF-8 HMAC 非拉丁字符按 UTF-8 编码。
Hex 输出 每字节两个十六进制字符 HMAC-SHA-256 为 64 个 Hex 字符。
Base64 输出 同一 HMAC 字节的 Base64 表示 编码变化不改变密码学结果。

HMAC 提供什么

HMAC 是标准消息认证构造,把秘密密钥与密码学哈希组合。持有同一密钥的验证方可以重算并发现消息变化;只看到消息和 HMAC 的攻击者不应能为修改消息生成有效代码。

HMAC 提供完整性和共享密钥真实性,但不加密消息,内容仍然可读。它也不提供不可否认性,因为任何密钥持有者都能生成同样代码。需要公钥验证和区分签名者时应使用数字签名。

  • HMAC-SHA-256 在 HMAC 构造中使用 SHA-256。
  • 输出长度与底层哈希一致。
  • 保密性需要独立加密。

密钥表示与管理

本页把密钥字段当作 UTF-8 文本。如果协议给出 Hex 或 Base64 密钥,通常那些字符只是原始密钥字节的编码。直接把编码字符作为文本会得到不同 HMAC。应按协议先解码,或使用明确支持密钥编码的实现。

安全性取决于密钥熵、存储和轮换。人类密码通常不是好密钥,除非协议规定 KDF。生产密钥应存秘密管理系统,限制访问、定期轮换并设置 key ID。禁止提交到代码仓库或支持工单。

  • 使用协议生成的随机密钥。
  • 区分原始字节与 Hex/Base64 文本。
  • 部署 Webhook 前设计轮换和吊销。

规范消息字节与 UTF-8

密钥和数据都通过 TextEncoder 编码为 UTF-8。HMAC 认证的是字节,不是抽象对象。换行、空格、Unicode 规范化、属性顺序、URL 编码和时间戳格式变化都会改变结果。对 JSON 验签时,重新格式化原文通常会破坏签名。

应捕获协议指定的原始请求体或精确拼接字符串,按指定分隔符组合字段,保留前导零,不要擅自把秒变成毫秒。多数 HMAC 集成失败来自规范化不一致,而不是算法错误。

  • CRLF 与 LF 是不同字节。
  • 末尾换行会改变 HMAC。
  • 视觉相同 Unicode 可能是不同规范化形式。

算法与输出编码

支持 HMAC-SHA-256、384 和 512,应选择 API、Webhook 或测试向量明确要求的算法。新方案常用 HMAC-SHA-256,但仍应经过协议审查。

Hex 和 Base64 只是结果字节的文本编码。验证方期待小写 Hex 时,Base64 不会匹配。部分协议使用 Base64url,而本页输出标准 Base64,包含 +、/ 和填充;只有协议明确要求时才转换。

  • HMAC-SHA-256 输出 32 字节。
  • Hex 大小写按协议处理。
  • 标准 Base64 不等于 Base64url。

Webhook 与 API 验证流程

健壮的 Webhook 验证会读取原始请求体,提取时间戳和 key ID,按协议重建签名字符串,用对应密钥计算 HMAC,并采用常量时间比较。还应检查时间窗口和重放标识。

本页适合测试向量和排查,不是生产 Webhook 端点。不要为了比对在共享浏览器中暴露生产密钥。生产验证应在可信服务器边界完成,并在执行业务动作前拒绝无效签名。

  • 协议要求原始字节时,应在解析前验证。
  • 拒绝过期时间戳以降低重放风险。
  • 安全代码使用常量时间比较。
  • 轮换期间按 key ID 选择密钥。

错误、限制与密钥处理

空密钥会被拒绝,因为几乎总是误操作。必须有 Web Crypto。密钥和消息只保存在当前页面状态,不主动写入日志、本地存储或 IndexedDB。清空后页面不再持有,但无法删除剪贴板历史和录屏。

本页只接受文本,不支持任意二进制密钥和文件,也不做密码 KDF、标签截断、常量时间比较或重放管理。高敏生产密钥应使用本地审计工具或受控应用环境,而不是普通浏览会话。

  • 不要在共享或受管设备粘贴生产密钥。
  • 复制敏感测试材料后清理剪贴板。
  • 除非协议明确分析过,不要截短 HMAC。

与普通哈希和加密的区别

普通 SHA 没有密钥,任何人都能对候选消息计算。HMAC 使用标准内外填充构造,不能用简单 hash(key || message) 替代,后者在某些哈希上可能有长度扩展等问题。

加密隐藏内容,但只有正确使用认证加密才同时保证完整性。HMAC 认证内容却不隐藏内容。不要自行拼接浏览器输出设计协议,应采用经过审查的标准。

常见问题

HMAC 是否等于哈希“密钥加消息”?

不是。HMAC 使用标准内外填充构造。简单 hash(key || message) 可能有结构性弱点,包括某些哈希的长度扩展风险。应直接使用 HMAC。

密钥和消息会上传或保存吗?

本实现只在浏览器编码并交给 Web Crypto,不主动上传或写入 localStorage、sessionStorage、IndexedDB。扩展、剪贴板管理器和设备监控不受页面控制。

可以直接粘贴 Hex 或 Base64 密钥吗?

只有协议说明字符本身就是密钥时才可以。多数情况下它们是原始字节的编码,需要先解码。本页把每个字符按 UTF-8 文本处理。

为什么格式化 JSON 后 HMAC 不同?

HMAC 认证精确字节。空格、属性顺序、换行和转义都会改变字节。应使用协议定义的原始请求体或规范字符串。

HMAC 能防止重放吗?

单独不能。需要把时间戳、nonce 或请求 ID 纳入认证,并在验证时限制时间窗口或记录已使用标识。

HMAC 会加密消息吗?

不会。它提供完整性和共享密钥真实性,消息仍可读。需要保密时使用经过审查的认证加密方案。

相关开发工具

查看全部工具

Cookie 偏好设置

管理你的 Cookie 偏好。必要 Cookie 无法关闭。

必要 Cookie

必要

用于语言选择、隐私选择和网站基础功能,属于必需项。

Cookie: NEXT_LOCALE

分析 Cookie

可选的分析 Cookie 可帮助我们了解访问情况并改进网站。

Cookie: _ga, _gid, _gat, _clck, _clsk

广告 Cookie

可选的广告 Cookie 可能用于展示相关广告并衡量广告效果。

Cookie: __gads, _gcl_au, IDE