4、常用密文检索方案介绍：Diana, OXT, IEX 等
聊到密文检索，很多同学第一反应就是“把数据加密存起来，查的时候全表解密”——那还叫密文检索吗？不行。真正的密文检索，是要在不解密的前提下完成查询。这听起来挺玄乎的，但业内确实有几个成熟的方案。
我做这个 SDK 改造之前，花了两周把 Diana、OXT、IEX 这三个方案翻了个底朝天。今天咱们就挨个过一遍，看看它们各自适合什么场景，以及我踩过的坑。
为什么需要多种方案？
先解决一个疑问：为什么不统一用一种？原因很简单——不同的业务需求和数据库结构，决定了你没法一招通吃。比如：
- 你需要在几百个字段里做模糊查询？
- 还是只查某一个字段的精确匹配？
- 数据量是百万级还是十亿级？
说白了，没有银弹。Diana、OXT、IEX 各自有擅长的战场。
Diana：双边加速的倒排方案
Diana 是我最早接触的方案。它的核心思想是利用双线性配对构建一个可搜索的倒排索引。你想想看，传统倒排索引是“词→文档ID列表”，但 Diana 把这个列表加密了，并加上双线性对来支持快速匹配。
优点：
- 查询速度非常快，理论复杂度 O(log n) 级别
- 支持多关键词布尔查询（AND/OR）
缺点：
- 建立索引的时间随关键词数量线性增长，粗估每10万个关键词需要5秒以上
- 双线性配对在客户端性能较差，移动端可能扛不住
我在项目里试过 Diana 做邮件正文搜索，结果客户端解密查询时发热严重。嗯，后来换成了 OXT。
OXT：安全且轻盈的对称加密方案
OXT（Oblivious Cross Tags）是目前工业界用得最多的方案。它基于对称加密加安全索引，不需要双线性对这样重量级的计算。原理大致是：为每个文档每个关键词生成一个“标签”，查询时通过计算标签匹配来定位。
我个人的偏好也偏向 OXT，因为它对客户端硬件要求低，适合桌面端集成。
注意：OXT 虽然查询快，但它不支持范围查询。如果你需要查“价格在100到200之间”，OXT 没法直接做，得走一些曲线手段。
IEX：为范围查询而生
IEX（Inverted Exponential）是专为范围查询设计的方案。它把数值型字段先进行分段编码（比如把100~200分成若干桶），然后加密存储。查询时直接定位到对应桶，再在桶内做精确匹配。
我曾经接手一个金融项目，要求对交易金额做密文范围查询，选取 IEX 后索引体积虽然大了30%，但查询速度比直接用 OXT 模拟快了一个数量级。
三个方案的决策关系
下面这张图总结了我选择方案时的思考路径，也方便你对照自己的需求快速判断。
避坑指南：我踩过的三个坑
- 坑一：用 Diana 做文本搜索，没注意客户端 CPU 瓶颈。后来增加了本地缓存 才解决。
- 坑二：OXT 的标签碰撞问题，我一开始用了太短的哈希（8字节），导致误报率爆表。改成16字节后稳定了。
- 坑三：IEX 的桶分得太细，导致索引膨胀到原始数据的 5 倍。调整桶步长后控制在 1.8 倍以内。
代码片段：OXT 查询接口示例
下面是一个简化的 OXT 查询调用，我把它封装在 SDK 里。先构建查询标签，然后服务端匹配。
from crypt_search import OXTClient, OXTServer
# 初始化客户端（桌面端）
client = OXTClient(master_key="your-256-bit-key")
# 创建查询标签
= client.create_query_(
field="email",
keyword="alice@example.com"
)
# 服务端执行密文检索
server = OXTServer(encrypted_index_path="./index.dat")
matched_ids = server.search()
print(f"匹配到 {len(matched_ids)} 个文档")
实际使用时，create_query_ 内部会用 HMAC 和伪随机置换生成不可逆的标签。我建议你对接前先跑一遍小数据集，确认延迟在自己的容忍范围内。
各方案适用场景总结
| 方案 | 最佳场景 | 不适用场景 |
|---|---|---|
| Diana | 多关键词布尔查询，学术、邮件搜索 | 客户端性能差、实时性要求高 |
| OXT | 单字段精确匹配，数据库按主键/邮箱查询 | 需要范围查询、模糊查询 |
| IEX | 数值范围查询，如金额、时间、温度 | 文本模糊搜索，多字段联合查询 |
最后说一句实在话：不要纠结于“哪个方案最好”。选一个能在你的数据量和查询模式下跑通的，然后做性能压测。我在上周的集成测试里，发现同一个 OXT 实现在 50 万和 200 万数据下的表现天差地别——这时候就该考虑是否切到 Diana 或者 IEX 了。