HMAC消息认证码生成器 - 密钥哈希在线计算

HMAC（Hash-based Message Authentication Code）是一种基于哈希函数的消息认证码机制。它结合一个秘密密钥和哈希算法（如 SHA256），对消息进行计算，生成一个固定长度的认证码。HMAC 能够同时验证消息的完整性（消息未被篡改）和真实性（消息确实来自声称的发送方）。广泛应用于 API 签名、JWT Token、OAuth、数据完整性校验等场景。

普通哈希函数（如 SHA256）是无密钥的，任何人输入相同的消息都能得到相同的哈希值，无法验证消息来源。而 HMAC 引入了密钥，即使消息相同，不同的密钥会产生完全不同的认证码。这使得 HMAC 能够验证消息是否来自持有正确密钥的发送方，提供身份认证能力。简单来说：哈希验证完整性，HMAC 同时验证完整性和身份。

HMAC 的核心计算公式为：
HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))
其中 H 是哈希函数，K 是密钥，m 是消息，⊕ 表示异或运算。HMAC 通过两次哈希运算——内层和外层——将密钥与消息混合，有效防止了长度扩展攻击和密钥泄露风险。这种设计使得 HMAC 比简单的 H(key || message) 更安全。

HMAC-SHA512 更安全，因为它使用 512 位的哈希函数，抗碰撞能力更强。但在实际应用中：
• HMAC-SHA256：性能更好，输出 256 位（64 字符 Hex），适用于大多数 Web API 签名、JWT 等场景，是最广泛使用的选择。
• HMAC-SHA512：安全级别更高，输出 512 位（128 字符 Hex），适用于高安全要求的金融、政府等领域。
对于绝大多数应用，HMAC-SHA256 已足够安全且性能更优。

不推荐在安全场景使用 HMAC-MD5。虽然 HMAC 结构能缓解 MD5 的部分弱点，但 MD5 本身已被证明存在严重的碰撞漏洞。在需要安全性保障的场景（如 API 认证、数据签名），应使用 HMAC-SHA256 或更高级别的算法。HMAC-MD5 仅适用于非安全性场景，如数据校验、去重等。

密钥是 HMAC 安全的核心。如果密钥泄露，任何人都可以伪造有效的 HMAC 认证码。
推荐密钥长度：
• 至少与哈希函数的输出长度相同（SHA256 → 256位 = 32字节）
• 使用密码学安全的随机数生成器生成密钥
• 密钥应严格保密，不要硬编码在代码中，使用环境变量或密钥管理服务存储
• 定期轮换密钥以提高安全性

常见应用场景包括：
• API 请求签名：验证 API 请求的合法性和完整性（如 AWS Signature、阿里云 API 签名）
• JWT Token：JSON Web Token 使用 HMAC 进行签名（HS256、HS512）
• OAuth 1.0/2.0：授权流程中的请求验证
• Webhook 验证：确保回调数据来自可信源
• 数据完整性校验：验证传输或存储的数据未被篡改
• 密码存储：结合盐值增强密码哈希安全性

• Hex（十六进制）：每个字节用两个十六进制字符表示（0-9, a-f），结果长度是原始字节数的2倍。例如 SHA256 输出 32 字节 → 64 字符。可读性好，调试方便。
• Base64：将二进制数据编码为 ASCII 字符集（A-Z, a-z, 0-9, +, /），结果长度约为原始字节数的4/3倍，比 Hex 更紧凑。SHA256 输出约 44 字符。
选择建议：API 传输常用 Base64（更短），日志和调试常用 Hex（更易读）。

不能。HMAC 是单向函数，无法从认证码反向推导出原始消息或密钥。这是哈希函数的固有特性。HMAC 的验证方式是：接收方使用相同的密钥和算法重新计算 HMAC，然后对比两个认证码是否一致。如果一致，则消息完整且来自可信源。

核心区别：
• HMAC：使用对称密钥（同一个密钥用于生成和验证），速度快，适合内部系统间通信。
• 数字签名（如 RSA、ECDSA）：使用非对称密钥对（私钥签名、公钥验证），提供不可否认性，适合公开验证场景。
简单类比：HMAC 像是两人之间的暗号，数字签名像是盖了章的公文——任何人都能验证章的真伪。