1. 密文索引与安全查询工程导论

当数据从本地数据库迁移到云上、从单方持有变成多方共享时，一个根本矛盾就出现了：数据要能被查询，但查询过程不能泄露数据本身。传统数据库索引（B+树、哈希表、倒排表）之所以高效，是因为它可以直接读取明文键值并比较大小；而一旦数据被加密，密文在密码学意义上与随机串无异，任何基于明文的排序、范围比较、前缀匹配都失效。密文索引与安全查询工程，正是研究"如何在密文之上重建可用的查询能力，同时把泄露控制在可证明、可接受的范围内"的一门交叉工程学科。

课程定位：它解决的是"可用性"与"机密性"的冲突

本课程不是密码学理论课，也不是普通数据库课，而是站在两者交界处的工程实现课。它假设你已经理解对称加密、哈希、公钥密码的基本概念，也熟悉 SQL 查询与索引结构，重点回答三个工程问题：

• 能查什么：等值查询、范围查询、前缀/模糊查询、布尔组合查询、连接查询，各自需要什么样的密码学原语支撑；
• 泄露多少：访问模式（access pattern）、搜索模式（search pattern）、结果规模等侧信道信息会被服务端观察到，如何建模并评估其风险；
• 代价多大：索引膨胀率、查询往返次数、客户端计算量、存储与带宽开销，如何在实际系统中取得平衡。

换句话说，本课程的目标不是追求"绝对不泄露"（那等于不可查询），而是追求可度量、可协商、可落地的安全查询方案。

核心问题：从明文索引到密文索引，丢失了什么

理解密文索引的难点，最好从"明文索引为什么快"反推。以一张用户表为例，明文索引依赖三个能力：保序比较（判断 a < b）、确定性映射（相同键落到相同位置）、局部性（相邻键在磁盘上相邻）。加密会破坏这三者：语义安全加密（如 AES-CBC、AES-GCM）使相同明文产生不同密文，确定性加密虽保留相等性却泄露频率分布，保序加密保留大小关系却泄露顺序信息。

因此密文索引工程的核心，就是有选择地、可证明地恢复部分能力。常见技术路线包括：

• 确定性加密 + 哈希索引：支持等值查询，泄露频率；
• 保序加密（OPE）/ 顺序保留哈希：支持范围查询，泄露顺序与近似分布；
• 可搜索加密（SE）：基于关键词—陷门机制，支持关键词检索，泄露访问模式；
• 同态加密（HE）/ 安全多方计算（MPC）：理论上可支持任意查询，但计算与通信开销大；
• 可信执行环境（TEE）：把索引与查询放进 enclave，用硬件隔离替代纯密码学，泄露面转向侧信道攻击。

这些路线并非互斥，实际系统常采用混合架构：等值走确定性索引，范围走保序结构，复杂分析走 TEE 或 MPC。

技术栈全景：一张图看清各层职责

下面这张图把密文索引与安全查询工程的技术栈按"数据层—索引层—查询层—安全层"四层展开，并标出每层的典型组件与它们之间的数据/控制流向。它不描述某个具体产品，而是帮助你建立全局坐标系：当你在后续章节学习某种方案时，能立刻定位它属于哪一层、依赖哪些下层能力、向上提供什么接口。

图中左侧虚线表示典型的信任边界：数据层与索引层通常部署在服务端（不可信或半可信），查询层中的陷门生成与结果解密在客户端完成，安全层则横跨两端，负责定义"允许泄露什么"。橙色虚线箭头表示安全约束会反向影响索引结构选择与查询改写策略——例如当泄露预算收紧时，可能需要从确定性索引切换到 TEE 辅助方案。

学习路线图：从单点技术到系统设计

本课程后续 29 章将沿着"原语—结构—查询—系统—攻防"的路径推进，建议按以下节奏学习：

1. 基础原语（第 2–6 章）：确定性加密、保序加密、可搜索加密、同态加密、TEE 的基本性质与适用边界。重点不是推导安全性证明，而是记住每种原语"保留了什么、泄露了什么"。
2. 索引结构（第 7–13 章）：哈希索引、B 树变体、倒排索引、前缀树、布隆过滤器在密文下的改造方式，以及索引膨胀率与查询代价的量化关系。
3. 查询工程（第 14–20 章）：等值、范围、布尔、连接、聚合查询的编译与执行，陷门设计，结果过滤与去重。
4. 系统与攻防（第 21–27 章）：泄露滥用攻击（频率分析、访问模式推断）、前向/后向安全、密钥轮换、多用户共享、性能调优。
5. 综合实践（第 28–30 章）：端到端案例，从需求分析、方案选型、参数配置到泄露评估与压测。

一个最小示例：等值查询的密文索引长什么样

为了让你对"密文索引"有具体手感，这里给出一个教学用的简化示例（参数为合理假设，非实测结果）。假设用户表有 id、name、age 三列，我们想对 name 做等值查询。采用确定性加密（如 AES-SIV）对 name 加密，相同明文得到相同密文，于是可以建立哈希索引：

-- 明文表
CREATE TABLE users (id INT, name TEXT, age INT);
-- 密文索引表（服务端可见）
CREATE TABLE users_enc (
  id_enc   BYTEA,   -- 确定性加密
  name_enc BYTEA,   -- 确定性加密，用于等值索引
  age_enc  BYTEA,   -- 随机化加密，不参与索引
  INDEX idx_name (name_enc)
);

-- 客户端查询 name = 'alice'
-- 1) 客户端计算 name_enc = DetEnc('alice')
-- 2) 发送: SELECT id_enc FROM users_enc WHERE name_enc = ?
-- 3) 服务端用哈希索引定位，返回 id_enc 列表
-- 4) 客户端解密 id_enc 得到真实 id

这个方案能工作，但服务端能看到：哪些行具有相同的 name_enc（频率泄露），以及每次查询命中了哪些行（访问模式泄露）。如果 name 的取值空间很小，攻击者可以通过频率分析把密文与明文对应起来。这正是后续章节要解决的典型问题。

本章建立了课程的坐标系：问题是可用性与机密性的冲突，方法是有选择地恢复查询能力并控制泄露，技术栈分为数据、索引、查询、安全四层，路线是从原语到结构、到查询、到系统、到攻防。接下来，我们将从最基础的确定性加密与哈希索引开始，逐步搭建完整的密文查询工程能力。