Hey folks, let's unpack these three core cryptography questions—they're essential for building secure systems, so great call asking about them!

碰撞抗性是哈希函数的核心安全属性之一。先搞清楚什么是"碰撞"：如果有两个完全不同的输入值 M1 和 M2（M1 ≠ M2），经过哈希运算后得到了相同的输出值 H(M1) = H(M2)，这就叫一次哈希碰撞。

碰撞抗性的定义很直白：找到这样的一对输入在计算上是不可行的。注意这里是"计算上不可行"，不是绝对不可能——因为哈希函数把任意长度的输入转换成固定长度的输出，从数学上来说必然存在碰撞（鸽巢原理），但现代安全哈希算法的设计目标是让攻击者需要花费天文数字级的计算资源才能找到碰撞，在现实场景中根本做不到。

它的工作原理依赖于哈希函数的两个关键设计特性：

• 混淆（Confusion）：输入的每一位都会影响输出的多个位，让攻击者没法通过输出反推输入的结构，也没法构造出能生成相同输出的另一个输入。
• 扩散（Diffusion）：输入的微小变化（比如改一个比特）会导致输出发生完全的、不可预测的变化（雪崩效应），进一步增加构造碰撞的难度。

举个例子：SHA-256、SHA-3这类现代哈希算法具备强碰撞抗性；而MD5已经被公开破解，攻击者能在短时间内构造出碰撞，所以现在已经不能用于安全场景了。

HMAC（Keyed-Hash Message Authentication Code）是一种结合了哈希函数和秘密密钥的消息认证机制——它既能验证消息的完整性（有没有被篡改），又能验证消息发送者的合法性（因为只有持有密钥的人才能生成正确的HMAC）。

和直接做"密钥+消息"的哈希不同，HMAC有一套标准化的、更安全的计算流程，目的是避免简单拼接带来的安全漏洞（比如长度扩展攻击）。它的核心工作流程可以用伪代码表示：

HMAC(K, M) = H( (K ⊕ opad) || H( (K ⊕ ipad) || M ) )

拆解一下步骤：

1. 预处理密钥：如果密钥 K 的长度超过哈希函数的块大小，先对 K 做一次哈希；如果太短，就用0字节填充到块大小。
2. 生成内部密钥：把预处理后的密钥和固定的内部填充字节 ipad（0x36，重复到块大小）做异或运算。
3. 第一次哈希：把内部密钥和原始消息 M 拼接，然后用哈希函数 H 计算哈希值。
4. 生成外部密钥：把预处理后的密钥和固定的外部填充字节 opad（0x5C，重复到块大小）做异或运算。
5. 第二次哈希：把外部密钥和第一次哈希的结果拼接，再用哈希函数 H 计算一次，最终得到的就是HMAC值。

这种双层哈希+异或的设计，让HMAC对各种攻击（比如密钥泄露、消息篡改）都有很强的抵抗力，是目前应用最广泛的消息认证方案之一。

HMAC实现身份验证的核心逻辑是：只有持有共享秘密密钥的通信双方，才能生成/验证正确的HMAC值。具体步骤可以分成几个阶段：

准备阶段 #

• 通信双方（比如客户端和服务器）预先协商并共享一个保密的密钥，这个密钥必须严格保密，不能泄露给任何第三方。

客户端发送请求时 #

1. 客户端准备好要发送的原始消息（比如API请求的参数、JSON报文等）。
2. 使用共享密钥和原始消息，按照约定的HMAC算法（比如HMAC-SHA256）生成对应的HMAC值。
3. 把原始消息和HMAC值一起发送给服务器——通常会把HMAC放在请求头（比如Authorization: HMAC <值>）或者消息的签名字段里。

服务器验证时 #

1. 服务器收到消息后，先提取出原始消息和客户端发送的HMAC值。
2. 使用自己保存的共享密钥，对原始消息执行和客户端完全相同的HMAC计算，得到本地生成的HMAC值。
3. 对比本地生成的HMAC值和客户端发送的HMAC值：
   • 如果两者完全一致，说明消息没有被篡改，且发送者确实是持有共享密钥的合法用户（第三方没有密钥，没法生成正确的HMAC）。
   • 如果不一致，说明消息可能被篡改，或者发送者是非法用户，服务器直接拒绝请求。

额外的安全优化 #

为了防止重放攻击（攻击者重复发送之前的合法请求），通常还会在原始消息中加入随机数（Nonce）或者时间戳，这样每次生成的HMAC都是唯一的，攻击者无法复用之前的请求。

内容的提问来源于stack exchange，提问作者Jony