🔏 HMAC计算
Web Crypto API · 多种算法 · Hex/Base64输出
Web Crypto API · 多种算法 · Hex/Base64输出
HMAC（基于哈希的消息认证码）是一种通过加密哈希函数和密钥来验证消息完整性和真实性的机制。广泛应用于API签名、JWT、OAuth等场景。
普通哈希（如SHA256）不需要密钥，任何人都能计算，只保证内容没被改动。HMAC需要密钥，只有持有密钥的人才能生成有效值，因此除了完整性还能验证来源真实性（认证）。
HMAC-SHA256是最常用选择，安全性好性能佳。HMAC-SHA512更安全但更慢。HMAC-MD5和HMAC-SHA1逐渐被淘汰，不建议用于新的安全场景。
先把密钥处理成固定长度（大于哈希块长就先哈希），然后做两次哈希：内层用密钥与ipad异或将消息打包，外层用密钥与opad异或将内层结果再包一层。这个"内哈希+外哈希"结构就是HMAC。
AES是可逆加密，能还原原文；HMAC是单向的摘要，不可还原，只用来"验签"。HMAC不隐藏内容——别人看得见明文，但改不了、伪造不了。
直接用SHA256(message)任何人都能算出，无法证明是谁签的。HMAC-SHA256(message, secret)因为掺入了只有你和服务器知道的密钥，别人无法伪造，所以适合做API签名和鉴权。
密钥长度建议不小于哈希摘要长度（如SHA256对应至少32字节）。密钥太短容易被字典攻击，太长也不会增加太多安全性（会先哈希）。用随机生成的密钥最佳。
不推荐。HMAC速度快，适合验签，但做密码哈希易被暴力破解。密码存储请用专门的慢哈希如bcrypt、scrypt、argon2。
HMAC的核心是"两次哈希"结构，形式上记作 HMAC(key,msg) = H( (key⊕opad) ∥ H( (key⊕ipad) ∥ msg ) )。
简单说：把密钥异或上固定的ipad/opad填充值，分别包住消息做一次内层哈希，再把结果用外层填充包住做第二次哈希。两个固定的填充值让输入无法被线性预测，从而抵御长度扩展攻击。
| 算法 | 底层哈希 | HMAC输出(Hex) | 推荐度 |
|---|---|---|---|
| HMAC-MD5 | MD5(128位) | 32字符 | 低，淘汰 |
| HMAC-SHA1 | SHA-1(160位) | 40字符 | 低，淘汰 |
| HMAC-SHA256 | SHA-256(256位) | 64字符 | 高，推荐 |
| HMAC-SHA512 | SHA-512(512位) | 128字符 | 高，更安全 |
很多人把HMAC和"把盐拼进哈希"（如 SHA256(salt+msg)）混为一谈，其实完全不同。
| 场景 | 消息 | 密钥归属 | 作用 |
|---|---|---|---|
| API签名 | 请求参数+时间戳 | 客户端/服务器共享 | 防篡改防重放 |
| JWT | Header+Payload | 签发方/校验方共享 | token防伪造 |
| Webhook | 回调内容 | 提供方/接收方共享 | 确认来源可信 |
| 云存储签名 | 请求头/URL | 服务端与SDK | 临时授权 |
在这些场景里，双方都持有同一个密钥，用HMAC对消息算签名，收到后再独立重算比对。只要密钥不泄露，伪造几乎不可能。
| 维度 | 普通哈希 | HMAC | 对称加密 |
|---|---|---|---|
| 是否需要密钥 | 不需要 | 需要 | 需要 |
| 能否逆推原文 | 不能 | 不能 | 能 |
| 能否验证来源 | 不能 | 能 | 取决场景 |
| 典型算法 | MD5/SHA | HMAC-SHA256 | AES |
| 典型用途 | 校验完整性 | 验签/认证 | 数据保密 |
| 消息 | 密钥 | HMAC-SHA256(Hex) |
|---|---|---|
| （与密钥相关，此处为示例格式） | ||
| abc | key | 74f2e52e6b...（请以工具实时计算为准） |
| Hello | secret | ...（请以工具实时计算为准） |
1. 输入消息文本。
2. 输入密钥。
3. 选择HMAC算法。
4. 查看Hex和Base64输出结果。