当加密ID需要变成Guid：为什么我选择了AES-CBC而非GCM？

在当代的密码学工程中，有一个非常主流的建议：“GCM 是现代加密的首选，应该优先考虑它，而不是像 CBC 这样的传统模式。” 这个建议在绝大多数情况下都很有道理。AES-GCM (Galois/Counter Mode) 凭借其卓越的性能、并行处理能力以及内置的认证加密 (AEAD) 特性，确实能提供远超 CBC (Cipher Block Chaining) 的机密性与完整性保障。
然而，作为在真实世界中构建软件的工程师，我们深知技术选型并非简单的“非黑即白”。在某些特定的、带有约束条件的场景下，我们是否真的只能选择 GCM？会不会存在一些“灰色地带”，让看似“过时”的 CBC 反而成为更务实、更巧妙的解决方案？
在我开发开源项目 Sdcb.Chats 的过程中，就遇到了这样一个有趣的场景。这段经历让我深刻体会到，真正的工程决策，是在深刻理解原理之后，基于具体需求所做的权衡与取舍（Trade-off）。本文将结合这段实践，深入探讨 GCM 和 CBC 之间那些不常被提及的选择考量。
GCM 的光环：为何它被誉为黄金标准？

在深入探讨“特例”之前，我们必须先充分肯定 GCM 的普适优势。简单回顾一下，GCM 之所以强大，主要在于：

• 认证加密 (AEAD)：这是 GCM 最核心的优势。它在加密数据（提供机密性）的同时，会生成一个认证标签（Authentication Tag）。这个标签能保证数据在传输过程中未被篡改（提供完整性）。任何对密文的修改都会导致标签验证失败，解密操作会直接抛出异常，从根本上杜绝了篡改风险，也让“填充预言攻击”等针对 CBC 的攻击方式成为历史。
  
• 高性能：GCM 的核心是 CTR (Counter) 模式，其加密过程可以被高度并行化。在支持 AES-NI 指令集的现代 CPU 上，GCM 的吞吐量通常远超需要串行加密的 CBC 模式。
  
• 无需填充：作为一种流加密模式，GCM 不需要对明文进行填充（Padding），可以直接处理任意长度的数据，代码实现更简洁，也避免了与填充相关的潜在安全问题。
  

总而言之，当你需要为一个新系统设计通用的、安全的网络通信协议或数据存储加密时，请毫不犹豫地选择 AES-GCM。
现实的骨感：当 GCM 的要求与需求冲突

在 Sdcb.Chats 项目中，我遇到了一个需求：将数据库中的自增 int 或 long 类型的 ID，在 API 和前端 URL 中展示为一个看起来随机、无规律的标识符，以防止信息泄露（如系统规模）和恶意猜测。同时，这个标识符最好能保持统一、简洁的格式。
这看似简单的需求，却让 GCM 的两个核心要求显得格外“碍事”。
冲突一：固定的 IV/Nonce 与 GCM 的“灾难性”后果

为了保证前端逻辑的稳定性（例如，基于 ID 的缓存和状态管理），我需要一个确定性的加密：对于同一个输入的整数 ID，加密后的字符串结果必须永远相同。
这意味着，我不能在每次加密时都使用随机生成的 Nonce (Number used once)。我必须为每种加密目的（如 ChatId, MessageId）使用一个固定的初始向量（IV），或者说，一个固定的 Nonce。
这对于 GCM 来说是绝对禁止的操作。GCM 的安全性基石在于，对于同一个密钥，Nonce 绝不能重复使用。一旦你用相同的密钥和 Nonce 加密了不同的明文（哪怕明文之间只有微小的差异，比如连续的整数 ID 1, 2, 3...），攻击者就可以通过简单的计算破解出密钥流，进而恢复所有明文。
让我们用代码直观地看一下后果。假设我们使用固定的 Nonce 来加密连续的整数：
[code]using System.Security.Cryptography;using System.Text;// 假设我们为某个加密目的，固定使用一个 Noncebyte[] key = RandomNumberGenerator.GetBytes(16);byte[] fixedNonce = RandomNumberGenerator.GetBytes(12);Console.WriteLine($"Key: {Convert.ToHexString(key)}");Console.WriteLine($"Fixed Nonce: {Convert.ToHexString(fixedNonce)}\n");using AesGcm aesGcm = new AesGcm(key, tagSizeInBytes: 16);for (int id = 1; id