HMAC 生成器
用文本、十六进制或 Base64 密钥计算消息的 HMAC-SHA256、SHA-384、SHA-512、SHA-224、SHA-1、MD5、SHA3 或 RIPEMD-160，实时输出十六进制或 Base64。
HMAC（RFC 2104）将密钥两次混入哈希：H((K ⊕ opad) || H((K ⊕ ipad) || message))。长于哈希分组的密钥会先被哈希。服务器端请用恒定时间比较 MAC。
什么是 HMAC 生成器？
为消息和密钥计算带密钥的哈希消息认证码（HMAC，RFC 2104）。支持 SHA-2、SHA-3、SHA-1、MD5 和 RIPEMD-160，密钥可以是文本、十六进制或 Base64，并在你输入时以小写/大写十六进制或 Base64 显示 MAC。
如何使用 HMAC 生成器
- 输入消息（文本，或把编码切换为 Hex 以输入原始字节）。
- 输入密钥，并选择它是文本 (UTF-8)、Hex 还是 Base64。
- 选择算法，例如 HMAC-SHA-256。
- 选择输出格式并复制 HMAC。
示例
Message "what do ya want for nothing?", key "Jefe", HMAC-SHA-256
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843
RFC 4231 测试用例 2。
何时使用 HMAC 生成器
用于验证 Webhook 签名（Stripe、GitHub、Shopify、Slack）、为 API 请求签名、调试 AWS 风格的签名步骤，或检查 HMAC 测试向量。它不适合用来哈希密码（请使用 bcrypt 或 Argon2），也不是数字签名：任何持有密钥的人都可以生成 MAC。
HMAC 生成器 的工作原理
HMAC(K, m) = H((K′ ⊕ opad) ‖ H((K′ ⊕ ipad) ‖ m))，其中 K′ 是用零填充到哈希分组大小的密钥（比分组更长的密钥会先被哈希），ipad = 0x36，opad = 0x5C，均按分组长度重复。即使对于 MD5 和 SHA-1 这类抗碰撞性已被攻破的哈希，这种构造依然安全。摘要来自 hash-wasm，结果与 RFC 4231 和 RFC 2202 的测试向量一致。
常见用例
- 验证 GitHub 的
X-Hub-Signature-256或 Stripe 的 Webhook 签名 - 调试时复现 API 请求签名
- 检查 RFC 4231 的 HMAC 测试向量
- 为遗留的 OAuth 1.0 或 TOTP 调试生成 HMAC-SHA1 值
- 对比两种语言之间结果不一致的输出
安全提示
密钥和消息都留在你的浏览器中。在服务器上请用恒定时间函数比较 MAC，以避免时序攻击。
常见问题
为什么我的 HMAC 与 Webhook 头部不一致？
请检查：是否逐字节地哈希了原始请求体（不要重新格式化 JSON）；是否使用了准确的密钥（有些服务商提供的是 Base64，或带有 whsec_ 之类的前缀）；以及预期的输出编码——GitHub 使用十六进制，Shopify 使用 Base64。
HMAC-SHA1 或 HMAC-MD5 仍然安全吗？
作为 MAC，它们没有实际可行的攻击，因为 HMAC 不依赖抗碰撞性。它们被视为遗留算法；新系统请使用 HMAC-SHA-256 或更强的算法。
密钥可以为空吗？
RFC 2104 允许，工具也会计算，但空密钥不提供任何安全性。
HMAC 与对“密钥 + 消息”做哈希相同吗？
不同。简单的 hash(key + message) 在 SHA-2 下易受长度扩展攻击；HMAC 的双重哈希可以防止这一点。