对称加密基础：AES、国密SM4，密钥管理

对称加密，说白了就是加密和解密用同一把钥匙。你想想看，就像你锁柜子，一把钥匙既能锁也能开。在密文检索的场景里，这把钥匙直接决定了你的数据在加密后还能不能被高效地搜索到。我刚开始接触这个领域时，总觉得加密就是套个壳，后来踩了很多坑才明白——选错密码算法，检索效率能差两个数量级。

为什么对称加密是密文检索的基石？

密文检索的核心，是在不泄露明文的前提下，让服务器能帮你找到需要的文档。对称加密速度快、开销小，是整个流程里最底层的保障。你问问自己：如果加密数据后，服务器无法区分两个不同的关键词碎片，那检索就完全失效了。所以对称加密不仅要保证安全性，还要保留一定的数学结构——这就是后面要讲的“可搜索加密”的起点。

AES 算法详解

AES（Advanced Encryption Standard）是目前全球最通用的对称加密算法。我个人习惯在项目里优先用 AES-256，尤其是在密文检索这类对安全等级要求高的场景。它有三种密钥长度：128、192、256 位，块大小固定 128 位。

工作模式对比

模式	特点	密文检索适用性
ECB	相同明文块生成相同密文块	不适用
CBC	每个块与前一个密文块异或	可用，但需要处理 IV
GCM	认证加密，支持并行	常用，但需留意 nonce 管理
CTR	计数值作为输入，可并行	适合构建可搜索加密方案

我在项目中遇到过一个大坑：一开始为了效率用了 ECB 模式加密关键词索引，结果发现相同的词加密后一模一样，攻击者直接能统计词频。嗯，从那以后我再也不敢用 ECB 来加密索引了。

国密 SM4 算法

SM4 是中国国家密码管理局发布的对称加密标准，块大小和 AES 一样是 128 位，但密钥长度固定 128 位。它的结构跟 AES 不同，使用的是 32 轮非线性迭代。

AES 与 SM4 对比

特性	AES-256	SM4
密钥长度	128/192/256 位	128 位
轮数	10/12/14	32
软件实现速度	快（有 AES-NI 指令集）	中等（无专用指令）
合规性	国际标准	国内金融、政务强制要求
密文检索适配	成熟方案多	需自行实现可搜索扩展

如果你做的是国内市场项目，尤其是金融或政务，SM4 几乎是绕不开的。我去年帮一家银行做数据安关，对方明确要求只能用 SM4。当时为了把 SM4 嵌入到密文检索流程里，费了不少功夫去改分词和索引结构。

密钥管理

算法选得再好，密钥管不好，一切等于零。密文检索场景下，密钥管理尤其重要——因为你要用同一个密钥来加密数据和生成搜索令牌。

密钥生命周期

• 生成：必须使用密码学安全的伪随机数生成器（CSPRNG）。不要用 Math.random() 或简单的 UUID。
• 存储：永远不要硬编码在代码里。建议使用密钥管理服务（KMS）或硬件安全模块（HSM）。
• 轮换：定期更换密钥，并支持旧密钥解密历史数据。我在一个项目里设计了双缓冲区密钥池——新密钥加密新数据，旧密钥留着解密旧数据，直到所有数据都重新加密过。
• 分发：客户端和服务端之间的密钥分发必须通过安全通道（如 TLS）。

实践中的选择建议

我个人的习惯是：

• 国际场景：首选 AES-256-GCM，既能加密又能认证，而且 GCM 模式支持并行，适合处理大数据块。
• 国内合规场景：用 SM4-CTR 或 SM4-GCM（如果 SDK 支持），注意检查是否获得国密型号证书。
• 密钥管理：一定不要在代码里留密钥。哪怕是小项目，也至少用环境变量 + 加密存储。

你想想看，如果把密文检索系统比作一座安全屋，对称加密就是那扇最核心的锁。锁的等级、钥匙的保管、换锁的流程，每一个细节都决定了屋子是否真正安全。

这个图展示了对称密钥在整个密文检索数据流中的位置：它既参与加密明文生成密文索引，也参与检索令牌的生成。你想想看，如果密钥管理出了问题，加密和检索两头都会塌。