🔐 HMAC 生成器

关于 HMAC 生成器

HMAC（基于哈希的消息认证码）是一种用于同时验证消息完整性和真实性的技术。它将密码学哈希函数与密钥结合，生成只有持有相同密钥的人才能复现的摘要。本工具可同时生成 HMAC-SHA1、HMAC-SHA256、HMAC-SHA384 和 HMAC-SHA512，全部通过 Web Crypto API 在浏览器本地计算——不上传任何数据。

工作原理

• 密钥哈希 —— HMAC 以特定方式（内层和外层填充）将密钥混入消息，使摘要同时依赖于消息和密钥。
• 公式 —— HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))，其中 K' 是填充/哈希到块大小的密钥，ipad 为重复的 0x36，opad 为重复的 0x5C。
• 验证 —— 接收方用共享密钥重新计算消息的 HMAC，并与收到的摘要比较。不匹配说明被篡改或密钥错误。
• Web Crypto API（crypto.subtle.importKey 和 crypto.subtle.sign）以原生安全方式执行实际计算。

使用场景

• API 请求签名 —— 许多 Web API（AWS、GitHub Webhook、Stripe）要求 HMAC 签名以验证请求来自已认证方。
• Webhook 验证 —— 验证 X-Hub-Signature-256 头，确认 Webhook 负载确实由声称的服务发送。
• 令牌派生 —— HMAC 是 HOTP/TOTP 一次性密码和 JWT 签名算法（HS256、HS384、HS512）的基础。
• 完整性校验 —— 当双方共享密钥时检测篡改，普通哈希不足以胜任。

常见问题

哈希和 HMAC 有什么区别？ 普通哈希没有密钥——任何人都能计算。HMAC 需要密钥，因此能同时证明数据完整性和真实性（发送方知道密钥）。

应该用哪种算法？ 新应用优先使用 HMAC-SHA256 或 HMAC-SHA512。HMAC-SHA1 在遗留系统（如 HOTP）中仍常见，但不再推荐用于新的安全敏感场景。

我的密钥会被发送到别处吗？ 不会。消息和密钥都通过 Web Crypto API 在浏览器本地处理，不上传任何内容。

密钥应该多长？ 经验法则：至少与哈希输出等长（如 SHA-256 用 256 位 / 32 字节）。避免短于 128 位的密钥。