签名、杂凑、MAC、HMAC
在数据保密性与完整性领域，签名（Digital Signature，数字签名）、杂凑（Hash，哈希）、MAC（Message Authentication Code，消息认证码）、HMAC（Hash-based Message Authentication Code，基于哈希的消息认证码） 是保障数据完整性、真实性的核心技术，其定义、核心思想、实现逻辑及关键特性存在明确差异，以下从客观角度详细拆解：
一、杂凑（Hash，哈希）
1. 定义
杂凑（哈希）是一种单向密码学函数，能将任意长度的输入数据（称为 “消息” 或 “明文”）映射为固定长度的输出值（称为 “哈希值”“摘要” 或 “指纹”），且输出长度仅由哈希算法本身决定（与输入长度无关）。
2. 核心思想
通过 “单向性” 和 “抗碰撞性” 确保数据完整性：
- 单向性：从哈希值无法反推回原始输入数据（即 “不可逆”）；
- 抗碰撞性：① 弱抗碰撞性 —— 难以找到两个不同输入对应相同哈希值；② 强抗碰撞性 —— 无法主动构造出两个不同输入对应相同哈希值。
最终实现 “数据一旦被篡改，其哈希值必然变化”，从而通过比对哈希值验证数据是否被修改。
3. 实现逻辑
- 预处理：对输入数据进行填充（如补零、添加长度信息），确保数据长度符合算法要求的分组长度整数倍（如 SHA-256 要求分组长度为 512 位）；
- 迭代压缩：将预处理后的数据按固定分组长度拆分，逐组代入哈希算法的压缩函数（如 SHA-256 的 64 轮压缩），每一轮通过逻辑运算（与、或、非、异或、循环移位等）更新中间哈希值；
- 输出结果：所有分组处理完成后，最终的中间哈希值即为固定长度的哈希值（如 SHA-256 输出 256 位，SHA-384 输出 384 位）。
4. 关键特性与适用场景
- 无密钥：计算哈希值无需依赖密钥，任何人都可对同一数据计算出相同哈希值；
- 仅保障完整性：无法验证数据来源的真实性（因无密钥，篡改者可重新计算篡改后数据的哈希值）；
- 典型算法：SHA-2 系列（SHA-256、SHA-384）、SHA-3 系列、MD5（已因抗碰撞性不足，不再用于安全场景）；
- 适用场景：文件完整性校验（如软件安装包校验）、数据去重、密码存储（将用户密码的哈希值存储，而非明文）。
二、MAC（Message Authentication Code，消息认证码）
1. 定义
MAC 是一种带密钥的完整性与真实性验证技术，通过 “消息 + 共享密钥” 生成固定长度的认证码，仅持有共享密钥的双方可验证认证码，从而同时确保数据 “未被篡改”（完整性）和 “来源合法”（真实性）。
2. 核心思想
在哈希的 “完整性验证” 基础上，引入 “共享密钥” 实现 “仅授权方（持有密钥）可生成 / 验证认证码”：
- 发送方：用共享密钥对消息计算 MAC，将 “消息 + MAC” 一起发送；
- 接收方：用相同共享密钥对收到的消息重新计算 MAC，若与收到的 MAC 一致，则确认消息未篡改且来源合法（非持有密钥者无法伪造 MAC）。
3. 实现逻辑
MAC 的实现依赖 “密钥 + 核心函数”，主要分为两类：
- 基于分组密码的 MAC（如 CBC-MAC）
- 步骤 1：将消息按分组密码（如 AES）的分组长度拆分，不足分组长度则填充；
- 步骤 2：用共享密钥对第一组消息进行分组密码加密，得到中间结果；
- 步骤 3：将中间结果与下一组消息进行 “异或” 运算，再用共享密钥加密，重复此过程直至所有分组处理完成；
- 步骤 4：最终一组的加密结果即为 MAC（通常会截取固定长度，如 128 位）。
- 基于哈希的 MAC（即 HMAC，单独拆解）
- 本质是将哈希函数与共享密钥结合，解决单纯哈希无密钥的问题。
4. 关键特性与适用场景
- 需共享密钥：依赖发送方与接收方预先协商的对称密钥（非对称密钥不适用）；
- 双向验证：发送方和接收方持有同一密钥，无法区分 “发送方身份”（即无法解决 “抵赖” 问题 —— 发送方可否认发送过消息）；
- 典型算法：CBC-MAC（基于 AES）、CMAC（CBC-MAC 的改进版，避免弱密钥问题）、HMAC；
- 适用场景：对称加密场景下的完整性 + 真实性验证（如 API 接口签名、本地网络数据传输验证）。
三、HMAC（Hash-based Message Authentication Code，基于哈希的消息认证码）
1. 定义
HMAC 是MAC 的一个具体实现类别，特指 “以哈希函数为核心，结合共享密钥生成认证码” 的技术，本质是 “哈希函数 + 密钥” 的组合，同时具备哈希的高效性和 MAC 的密钥验证能力。
2. 核心思想
解决 “单纯哈希无密钥” 和 “基于分组密码的 MAC 效率低” 的问题：
- 利用哈希函数的高效性（比分组密码加密更快），同时通过密钥注入，让哈希值与密钥绑定 —— 仅持有密钥者可生成正确的 HMAC，既保障完整性，又验证来源真实性。
3. 实现逻辑（严格遵循 RFC 2104 标准）
设：H为哈希函数（如 SHA-256），K为共享密钥，M为消息，ipad（0x36 重复填充至哈希分组长度）、opad（0x5C 重复填充至哈希分组长度）为固定常量，具体步骤：
- 密钥预处理：若
K长度大于H的分组长度，先对K计算哈希值，得到与分组长度一致的密钥K'；若K长度小于分组长度，直接用 0 填充至分组长度，得到K'； - 计算内层哈希：将
K'与ipad进行 “异或” 运算，得到K'^ipad；将M拼接在K'^ipad后，计算哈希值H(K'^ipad || M)； - 计算外层哈希：将
K'与opad进行 “异或” 运算，得到K'^opad；将内层哈希结果拼接在K'^opad后，计算哈希值H(K'^opad || H(K'^ipad || M))； - 输出 HMAC：最终的外层哈希结果即为 HMAC 值（长度与
H的输出长度一致，如 SHA-256 对应 HMAC 长度为 256 位）。
4. 关键特性与适用场景
- 依赖哈希函数：哈希函数的安全性直接决定 HMAC 的安全性（如用 SHA-256 的 HMAC 比用 MD5 的 HMAC 更安全）；
- 对称密钥：与 MAC 一致，需发送方和接收方共享对称密钥；
- 高效性：比基于分组密码的 MAC（如 CBC-MAC）计算速度更快，适合大数据量场景；
- 典型算法：HMAC-SHA256、HMAC-SHA384、HMAC-SHA1（SHA1 安全性下降，逐步被替代）；
- 适用场景：互联网场景的高效验证（如 HTTP 接口签名、JWT 的 HS256 算法、SSL/TLS 握手阶段的完整性验证）。
四、签名（Digital Signature，数字签名）
1. 定义
数字签名是一种基于非对称密码学的身份认证与完整性技术，通过 “私钥签名、公钥验证” 实现：仅持有私钥者可生成签名，任何人可通过公钥验证签名，从而同时保障数据的 “完整性”“真实性” 和 “不可抵赖性”。
2. 核心思想
利用非对称密码学的 “私钥唯一持有、公钥公开可查” 特性，解决 MAC 的 “无法抗抵赖” 问题：
- 签名方（如用户 A）用自己的私钥对消息（或消息的哈希值）生成签名；
- 验证方（如用户 B）用签名方的公钥对 “消息 + 签名” 进行验证，若验证通过，则确认：① 消息未被篡改（完整性）；② 签名确为由私钥持有者生成（真实性）；③ 签名方无法否认签名行为（不可抵赖性）。
3. 实现逻辑（主流为 “哈希 + 非对称加密” 组合，因直接加密消息效率低）
设：SK为签名方的私钥，PK为对应的公钥，H为哈希函数，M为消息，具体步骤：
- 消息哈希：对原始消息
M计算哈希值H(M)（压缩消息长度，提高加密效率，同时保障完整性）； - 私钥签名：用签名方的私钥
SK对哈希值H(M)进行 “非对称加密”（或特定的签名算法运算，如 RSA 的签名是对H(M)进行私钥解密，本质是特殊的非对称运算），得到签名s； - 发送数据：将 “原始消息
M+ 签名s” 一起发送给验证方； - 公钥验证：
- 验证方先用相同的哈希函数计算
M的哈希值H'(M)； - 再用签名方的公钥
PK对签名s进行 “非对称解密”（或对应验证运算），得到H''(M)； - 若
H'(M) = H''(M)，则签名验证通过；否则验证失败（消息被篡改或签名伪造）。
- 验证方先用相同的哈希函数计算
4. 关键特性与适用场景
- 非对称密钥：私钥唯一（签名方持有，需严格保密），公钥公开（可通过证书链验证合法性，避免公钥被篡改）；
- 抗抵赖性：核心区别于 MAC—— 因私钥唯一，签名方无法否认签名行为（可作为法律证据）；
- 典型算法：RSA-SHA256（RSA 签名 + SHA256 哈希）、ECDSA-SHA256（椭圆曲线签名 + SHA256，效率高于 RSA）、EdDSA（如 Ed25519，更高效、安全的椭圆曲线签名算法）；
- 适用场景：需身份认证与抗抵赖的场景（如电子合同签名、软件发布签名、区块链交易签名、数字证书 issuance）。
五、其他类似概念
除上述四类核心技术外，数据完整性与真实性领域还有以下常用概念：
概念 | 定义与核心思想 | 与前述技术的区别 |
CMAC（Cipher-based MAC） | 基于分组密码的 MAC 改进版，解决 CBC-MAC 的 “弱密钥” 和 “相同密钥下不同长度消息的碰撞” 问题，通过引入 “子密钥” 增强安全性。 | 属于 MAC 的子类，比传统 CBC-MAC 更安全，适用于对分组密码依赖度高的场景（如硬件加密设备），区别于 HMAC 的 “基于哈希”。 |
GMAC（Galois/Counter Mode MAC） | 基于 AES-GCM 模式的认证码，属于 “认证加密（AE）” 的一部分，在加密数据的同时生成认证码，兼顾保密性与完整性。 | 并非独立的认证技术，而是与加密绑定（“一站式” 解决保密 + 完整性），区别于 MAC/HMAC 仅做认证、不做加密。 |
数字签名标准（DSS） | 美国 NIST 制定的数字签名规范（如 FIPS 186-4），定义了 ECDSA、RSASSA-PSS 等签名算法的实现标准，本身不是技术，而是算法合规框架。 | 是数字签名的 “技术标准”，而非独立技术，前述的 RSA-SHA256、ECDSA 均需符合 DSS 规范才能用于合规场景（如政府项目）。 |
Merkle 树（哈希树） | 一种基于哈希的树形数据结构，叶子节点为数据块的哈希值，非叶子节点为其子节点哈希值的组合哈希，根节点为整个树的 “根哈希”。 | 本质是哈希的扩展应用，用于批量数据的完整性验证（如区块链的区块验证、分布式存储的数据一致性校验），区别于单一哈希仅验证单条数据。 |
六、核心技术对比总结
技术 | 密钥类型 | 核心能力（完整性 / 真实性 / 不可抵赖） | 可逆性 | 典型场景 |
杂凑（Hash） | 无密钥 | 仅完整性 | 不可逆 | 文件校验、密码存储 |
MAC | 对称密钥 | 完整性 + 真实性 | 不可逆 | 对称加密场景的接口签名 |
HMAC | 对称密钥 | 完整性 + 真实性（高效） | 不可逆 | HTTP 接口、JWT |
数字签名 | 非对称密钥（私钥签名、公钥验证） | 完整性 + 真实性 + 不可抵赖性 | 不可逆 | 软件发布签名（如代码签名）、区块链交易签名、数字证书签发 |