重放攻击与随机数重复使用漏洞

随机数（只使用一次的数值）可以确保同一条明文消息加密两次后产生不同的密文。这对于语义安全至关重要：攻击者即使观察到多条密文，也无法得知它们加密的是相同还是不同的明文。在流密码和 CTR 模式分组密码中，随机数会为密钥流生成过程提供种子，因此对安全性极为重要。

在 AES-GCM 中，96 位随机数用于初始化 CTR 模式加密的计数器，同时也参与 GHASH 认证计算。每个 AES 分组的计数器值都通过从该随机数开始递增得到。如果两次加密使用相同的随机数和密钥，就会生成相同的密钥流，使两段密文的 XOR 等于两段明文的 XOR。

使用相同的（密钥、随机数）组合加密得到的两段 GCM 密文，其 XOR 等于对应两段明文的 XOR。如果攻击者知道其中一段明文（在选择明文场景中很常见），就能立即恢复另一段明文。即使不知道任何明文，密文的 XOR 也会泄露语言模式，并且可以通过明文猜测拖拽技术进行攻击。这是密码学中最灾难性的误用模式之一。

GCM 随机数重用除了会导致明文泄露，还会带来另一个灾难性后果。GHASH 认证密钥 H 完全由加密密钥派生而来。如果两条消息共享同一个（密钥、随机数）组合，攻击者就可以求解多项式方程来恢复 H。获知 H 后，攻击者可以为任意密文伪造有效的 GCM 认证标签，从而彻底破坏消息完整性。

TLS 1.3 吸取了 TLS 1.2 实现中随机数重用风险的教训。TLS 1.3 通过将 12 字节的写入 IV（由握手派生）与 8 字节的序列号（零扩展为 12 字节）进行 XOR，生成 GCM 随机数。由于序列号会随每条记录递增，每条记录都会使用唯一的随机数。这既消除了生成随机数的风险，又通过序列号机制确保了随机数的唯一性。

重放攻击会捕获一条有效消息或认证令牌，稍后重新发送，以造成欺诈性结果。例如：重放银行交易以重复扣款，重放有效的认证响应以冒充用户，或重放已签名的设备命令。攻击者不需要理解或修改消息；只需重新发送捕获的数据即可完成攻击。

在经过认证的消息中加入时间戳，可以提供重放保护。接收方只接受处于短时间窗口内的消息（例如，声称的时间戳前后 5 分钟内）。数小时前重放的消息超出该窗口，就会被拒绝。时间戳必须经过认证（包含在 HMAC 或 AEAD 附加数据中），以防止攻击者修改时间戳，使消息看起来像是刚刚生成的。

与时间戳相比，序列号可以提供更强的重放保护，因为它不仅能检测旧消息的重放，还能检测重复投递和乱序投递。接收方会维护预期的下一个序列号，以及一个记录近期已见序列号的滑动窗口。每条消息的序列号都必须处于可接受的窗口内，且此前未出现过。TLS 使用序列号来防止会话内的记录重放。

对于 AES-GCM，随机随机数的推荐生成策略是使用密码学安全的伪随机数生成器（CSPRNG）生成 96 位随机数。对于 96 位随机数，经过 2^32 次加密（约 40 亿次）后，按照生日界计算的碰撞概率会达到 2^-32。对于高吞吐量应用，应改用基于计数器的随机数，或使用其他 AEAD（例如采用 192 位随机数的 XChaCha20-Poly1305），以扩大安全使用上限。

确定性的基于计数器的随机数可以避免生日界问题，但需要谨慎管理状态。计数器必须在应用重启后继续保留；如果计数器在重启时重置为零，就会立即与相同密钥产生随机数重用。计数器必须在随机数使用之前以原子方式更新（而不是之后更新）。对于分布式系统，基于计数器的随机数需要进行协调，以防两个节点使用相同的计数器值。

XChaCha20-Poly1305 将 ChaCha20-Poly1305 的随机数长度从 96 位扩展到 192 位。对于 192 位随机数，即使经过 2^96 次加密（消息数量大到几乎无法想象），按照生日界计算的碰撞概率仍然可以忽略不计。因此，生成随机数时无需担心实际的生日界问题。libsodium 的 crypto_secretbox（XSalsa20-Poly1305）也使用 192 位随机数，原因相同。

随机数重用回顾：随机数确保密文具有唯一性；GCM 中重用随机数会泄露明文的 XOR，并通过恢复 H 破坏认证；TLS 1.3 使用序列号与 IV 的 XOR 来保证随机数唯一；重放攻击会在不修改有效消息的情况下重新发送它们；在经过认证的消息中加入时间戳和序列号可以防止重放；对于 GCM，应使用 96 位随机随机数（注意生日界），或者使用 XChaCha20 以获得更大的随机数空间。