【数据库研究前沿】加密查询的边界：FHE、可搜索加密与 PIR

这是【数据库研究前沿】系列的第 21 篇，也是”数据库隐私三连”的最后一篇。第 19 篇 TEE 数据库走的是”硬件信任”路线，第 20 篇差分隐私走”统计保证”路线；本篇回答纯密码学能做到什么：没有可信硬件，也不假设攻击者看不到输出，仅靠加密算法本身，能不能在密文上查询数据？

这不是一个新问题。Rivest、Adleman、Dertouzos 在 1978 年提出”Privacy Homomorphisms”后的 30 年里，全同态加密（Fully Homomorphic Encryption, FHE）一直被认为是”理论上可行但工程上无法接受”。Gentry 在 STOC 2009 的 Fully Homomorphic Encryption Using Ideal Lattices 给出第一个 FHE 构造后，这一领域经历了 BGV（2011）、BFV（2012）、GSW（2013）、CKKS（2017）多轮迭代，工程开销从”每个乘法几个小时”压到”每秒数千次”。但与此同时，数据库社区发现：加密查询不必非要 FHE，可以分层——CryptDB（SOSP 2011）的 Onion Layering、可搜索加密（Searchable Encryption, SE）、Private Information Retrieval（PIR）都是”在特定查询形态下比 FHE 轻得多”的方案。

本文上半梳理四条技术路线及其代表系统；下半讨论真实业务里哪些查询形态能跑、哪些不能，以及银行、医疗、广告三类场景的落地模式。

版本说明 本文以 Microsoft SEAL 4.1、OpenFHE 1.2、HElib 2.3、PALISADE 已归档（并入 OpenFHE）、SealPIR / OnionPIR / Spiral 的 2024 开源版本为主要参照。FHE 与 PIR 领域论文密集，标注”（待核实）“的条目以公开论文为准。

一、全同态加密（FHE）：从理论可行到工程可用

1.1 FHE 的基本要求

一个公钥加密方案是同态（Homomorphic）的，如果存在运算 \(\oplus, \otimes\) 使得：

\[ \text{Dec}(\text{Enc}(m_1) \oplus \text{Enc}(m_2)) = m_1 + m_2 \]

\[ \text{Dec}(\text{Enc}(m_1) \otimes \text{Enc}(m_2)) = m_1 \cdot m_2 \]

如果 \(+\) 和 \(\cdot\) 都支持，称为全同态。RSA 只支持乘法（部分同态），Paillier 只支持加法（部分同态），都不够。真正意义上的 FHE 要在任意计算深度下保持正确性，技术难点在于每次同态运算会引入”噪声”，噪声积累到一定程度后密文不可解密。

这个”噪声会爆炸”的特性决定了 FHE 的一整套工程学：noise budget 成为和 “内存” “CPU 时间”并列的一类资源，需要在编译期预算、运行期监测。BFV 的 noise 用 invariant noise 衡量，CKKS 则是相对精度；工具链如 Microsoft EVA、Zama Concrete 的”噪声自动推导”就是为了把这件事从开发者手里拿走。

1.2 三代 FHE 方案

FHE 方案按”明文编码 + 底层困难问题”可以划代：

第一代（Gentry 2009）：Ideal Lattice，支持 boolean 电路，每个门操作要花数分钟。只证理论可行，无法工程化。
第二代（2011–2013）：BGV（Brakerski-Gentry-Vaikuntanathan）、BFV（Brakerski-Fan-Vercauteren）、GSW（Gentry-Sahai-Waters）。基于 LWE / RLWE 困难问题，引入 Modulus Switching 和 Key Switching，同态乘法成本降到毫秒级。明文是整数，适合精确计算。
第三代（2017 起）：CKKS（Cheon-Kim-Kim-Song，ASIACRYPT 2017）把明文改成”带误差的浮点数”，对 ML、统计分析非常友好。TFHE（Chillotti 等，2016/2020）专注布尔电路的快速自举（Bootstrapping）。

一张对比：

方案	明文类型	强项	典型延迟（单次乘法）
BGV / BFV	整数向量	精确聚合、计数	1–10 ms
CKKS	近似浮点	向量点积、ML 推理	1–10 ms
TFHE	单 bit	布尔电路、快速 bootstrap	0.01 s 级 bootstrap
GSW	整数	理论性质最优	工程实现少

这张表的延迟是大致量级，与参数（ring degree、modulus 大小）密切相关。

1.3 主流开源库：SEAL 与 OpenFHE

Microsoft SEAL（2018 开源）是最早的高质量工业级 FHE 库，实现 BFV / CKKS；OpenFHE（2022 年由 PALISADE、HElib 部分贡献者合并）实现 BGV / BFV / CKKS / TFHE / FHEW 几乎所有主流方案，是目前最活跃的 FHE 库。HElib（IBM）历史悠久，偏 BGV 研究。TFHE-rs（Zama）用 Rust 实现 TFHE，瞄准高性能推理。

各家 API 都长得差不多：用户构造 context、key_pair、encoder、encryptor、evaluator 几个对象，然后在密文上调 add、multiply、rotate。工程上真正的难点不在 API，而在：参数选择（safety level vs 性能）、noise budget 管理、批处理（batching / SIMD-like ntt packing）。

举个 SEAL 的伪代码：

auto context = SEALContext(parms);
KeyGenerator keygen(context);
// ciphertext = Enc(plaintext_vector)
Ciphertext c1, c2;
encryptor.encrypt(plain1, c1);
encryptor.encrypt(plain2, c2);
// homomorphic addition & multiplication
evaluator.add_inplace(c1, c2);
evaluator.multiply_inplace(c1, c2);
// key switching back to input-space
evaluator.relinearize_inplace(c1, relin_keys);

每一次 multiply 都消耗”noise budget”，用完必须 bootstrap，或者（更常见的工程做法）选足够大的参数让 bootstrap 完全用不到。实际项目里，选参数是 70% 的工作量。

1.4 自举（Bootstrapping）与为什么 FHE 贵

FHE 的核心技术挑战是 Bootstrapping：对密文同态地解密，产生一个”新的、噪声更小的密文”。这等于用密文算解密电路，开销极大——早期 Gentry 构造里一次 bootstrap 可能是分钟级，现在 CKKS 的 bootstrap 做到秒级、TFHE 做到百毫秒。

真实系统一般有两种策略：

Leveled FHE：一开始设定好深度 \(L\)，参数足够大以支持 \(L\) 次乘法，完全不 bootstrap。适合计算图固定、深度可预知的场景（ML 推理、固定模板查询）。
Full FHE：允许无限深度，需要定期 bootstrap。适合交互式查询。

数据库场景里绝大多数用 Leveled FHE，因为查询深度通常是可编译期确定的（SELECT / WHERE / 聚合等），不需要 runtime bootstrap。

一个常被混淆的细节：安全性不是由”FHE 还是 SHE”决定，而是由底层 LWE 参数决定。Leveled FHE 和 Full FHE 在等价参数下安全强度相同，选择只是工程 tradeoff。选错参数（比如 ring degree 过小）不管哪种模式都会掉到子指数级攻击下。HomomorphicEncryption.org 给出了按安全级别（128 / 192 / 256 bit）的参数推荐表，生产系统几乎必须照抄——自己调参出事故的概率太高。

1.5 FHE 在数据库上的现状

真正的”全同态数据库”几乎没有——一个纯 FHE 实现的 SELECT * FROM t WHERE a > 30 AND b < 100 现在仍然要几秒到几十秒来处理 100 万行。但 FHE 在以下细分场景已经量产：

加密推理（Encrypted ML Inference）：银行、医疗把模型输入加密后送到推理服务，返回加密结果。Microsoft SEAL、Zama Concrete 都有大量这类部署。
加密求和 / 平均：BGV / BFV 上做 SUM / COUNT 非常便宜（几乎等同于密文加法）。
加密比较（SortingHat 等）：专门为 ORDER BY / 范围谓词做的 FHE 优化，2022 年后开始成熟。
私有集合求交（Private Set Intersection, PSI）：严格说不完全属于 FHE，但很多实现用 FHE 做。广告行业用得多。

把”全同态 SQL”当成现实目标是不合理的；把”关键列的加密聚合”当成现实目标是完全可行的。这个区分是数据库工程师接触 FHE 时最需要建立的直觉。

一个常被低估的工程要素是密文膨胀（Ciphertext Expansion）：BFV / CKKS 的密文通常是明文的数百到数千倍大小。一列原本 10 GB 的整数，加密后可能膨胀到几百 GB。这直接影响存储成本、网络带宽和 I/O 策略——FHE 列要单独分区、压缩策略也与明文列不同。仓库中列存压缩实战讨论的大部分技术在 FHE 列上都不再适用，需要重新设计。

二、CryptDB 与可搜索加密

2.1 CryptDB（SOSP 2011）：洋葱加密的聪明妥协

Popa、Redfield、Zeldovich、Balakrishnan 在 SOSP 2011 的 CryptDB: Protecting Confidentiality with Encrypted Query Processing 走了一条和 FHE 完全不同的路：不用一种加密做所有事，而是同一列同时用多层加密（Onion），按查询需要解开到合适层。

CryptDB 定义了四层（由强到弱）：

RND（Random）：标准 IND-CPA 加密，最强但什么运算都做不了。
DET（Deterministic）：相同明文加密结果相同，支持等值查询。
OPE（Order-Preserving Encryption）：密文保持大小顺序，支持范围 / ORDER BY。
HOM（Homomorphic）：支持加法（通常用 Paillier），支持 SUM。

代理（Proxy）拦截 SQL 查询，根据谓词类型决定把对应列”剥开”到哪一层，然后把改写后的 SQL 送给无改动的 MySQL。这个设计让 CryptDB 在 TPC-C 上只带来 14.5% 的开销——在 2011 年是震惊业界的数字。

CryptDB 的代价和争议：

信息泄漏可量化。Naveed、Kamara、Wright 在 CCS 2015 的 Inference Attacks on Property-Preserving Encrypted Databases 证明：对医疗 / 人口数据，DET + OPE 层可以被分析攻击还原大部分明文。后续系列工作（Leakage Abuse Attack）成为一个独立子领域。
密钥与代理。代理要持有密钥来做层切换，代理本身成了敏感组件。CryptDB 假设代理可信，这与”不可信云”的初衷有一点矛盾。

即便如此，CryptDB 的”按查询形态分层选加密”思想几乎被之后所有加密数据库产品（Always Encrypted、CipherDB、EncSQL 等）继承。从某种意义上说，CryptDB 是把”密码学原语的组合工程化”的开山之作——它承认了一个朴素但深刻的事实：通用解太贵，分层解才现实。同时它也暴露了一个结构性难题：“剥层不可逆”——一旦某列被降到 DET，安全等级不会自动回升，任何事后提升需要重新加密全列。这个问题至今没有完美解，主流做法是一开始就按”最松允许的谓词类型”选层。

2.2 现代 CipherDB 与改进方向

CryptDB 之后的改进主要沿两条路：

更安全的 Order-Revealing Encryption（ORE）：保持顺序但只暴露”序关系”而非”距离”。Chenette 等 2016 的 ORE 是代表。
结构化加密（Structured Encryption, STE）：由 Chase、Kamara 2010 提出，把数据结构本身（B+ 树、倒排索引）加密为”可查询结构”。真实产品里用得最多，因为它允许 sub-linear 搜索。

工业界今天见到的”CipherDB”类产品（例如某些国产金融数据库），基本是 “CryptDB 思想 + ORE/STE 升级 + TEE 兜底” 的组合。

2.3 可搜索加密（Searchable Encryption, SE）

可搜索加密专注于一个具体问题：怎么在加密的集合里找包含关键词的文档？ Song、Wagner、Perrig 在 IEEE S&P 2000 的 Practical Techniques for Searches on Encrypted Data 是起点；后续 Curtmola 等的 SSE（Symmetric Searchable Encryption，CCS 2006）给出了严格的泄漏函数（Leakage Function）定义。

SE 的分类：

SSE（对称）：数据拥有者 = 搜索方，性能最好，Dropbox、Seagate 等曾用在加密云存储。
ASE（非对称）：数据拥有者 ≠ 搜索方，比如任何人都能加密写入、只有持密钥者能搜。代价高得多。
前向 / 后向安全（Forward / Backward Privacy）：增删文档后，新旧查询之间的泄漏如何约束。2016 年后成为主流评价维度。

SE 的终极难题是 泄漏 vs 性能的 tradeoff：完全不泄漏访问模式就必须退化到”全扫描”（线性），而 sub-linear 搜索一定会泄漏某种索引结构。学术界普遍承认：对于关键词搜索，完全 leakage-free 且 sub-linear 是不可能的。一系列 Leakage Abuse Attack（Cash 等 CCS 2015、Kornaropoulos 等 S&P 2020）证明了哪怕极小的访问模式泄漏也足够还原大量文档，这让 SE 的可信研究在 2020 年后转向更严格的”可量化泄漏”模型。

工程落地上，SE 基本只用在”加密邮件 / 加密文件存储”这类场景。关系数据库里的 LIKE、全文索引通常通过 TEE 或前端分词后 SSE 的组合方案实现。一个务实的做法是：“关键词倒排索引”做 SSE，“属性等值 / 范围”做 CryptDB 那样的分层加密，两者共用同一份密文列存——这是若干国产金融数据库实际采用的路线。

三、私有信息检索（PIR）：SealPIR、OnionPIR 与 Spiral

3.1 PIR 问题定义

私有信息检索（Private Information Retrieval, PIR）由 Chor、Goldreich、Kushilevitz、Sudan 在 FOCS 1995 提出：客户端从服务器有 \(n\) 条记录的数据库里取第 \(i\) 条，服务器不能知道 \(i\) 是多少。

PIR 有两种基本模型：

信息论 PIR（IT-PIR）：要求多台互不串通的服务器。现实中很难找到”独立”的服务器。
计算 PIR（cPIR）：单服务器，靠密码学假设（LWE / RLWE / DDH）。更实用但开销大。

一个朴素的 PIR：客户端把 0/1 向量加密后送给服务器，1 在第 \(i\) 位。服务器对加密向量和数据库做同态内积，返回加密的第 \(i\) 条。问题是：通信量与 \(n\) 成正比——1 GB 数据库要传 1 GB 的密文向量，完全不可用。

3.2 SealPIR、OnionPIR、Spiral：降通信的三代

Angel、Chen、Laine、Setty 在 S&P 2018 的 PIR with Compressed Queries and Amortized Query Processing 开启 SealPIR 时代：把查询向量做成多维 (d-dimensional)，通信量从 \(O(n)\) 压到 \(O(d \cdot n^{1/d})\)。对 \(n = 2^{20}\)，通信量降到百 KB 级。

Mughees、Chen、Ren 在 CCS 2021 的 OnionPIR 进一步优化：把 RLWE 密文嵌套几层（像洋葱一样），通信量降到单次 ~100 KB，计算吞吐也有提升。

Menon、Wu 在 S&P 2022 的 Spiral 是当前公开论文中性能最好的 cPIR：对 1 百万条 256-byte 记录，查询通信 14 KB，服务器计算 1.9 秒。比 SealPIR 快数十倍。Spiral 的关键技术是 composable 的 “regev-to-gsw” 转换，把密文切换开销压到极低。

一张对比（数量级）：

方案	查询通信	服务器计算（1M × 256B）	年份
Naive RLWE PIR	数 MB	数十秒	<2018
SealPIR	数百 KB	数秒	2018
OnionPIR	~100 KB	1–2 s	2021
Spiral	14 KB	~1.9 s	2022

几个值得注意的趋势：第一，从多轮 PIR 走向单轮。SealPIR 之前常需要 client-server 多次交互，现在主流是”一个 query、一个 response”的无状态形态，对无连接网络（CDN、边缘）更友好。第二，预处理的引入。近期论文（Simple PIR / DoublePIR，2023）提出让 client 预先下载一个公开”hint”，此后每次查询都极快。这让 PIR 的摊销成本进一步下降，但代价是客户端需要定期更新 hint，和 3.3 节讨论的”更新问题”互相纠缠。

3.3 PIR 在数据库里的位置

PIR 擅长”给定行号取一行”，它天然对应主键点查。但 PIR 不擅长：

范围查询：需要把范围拆成多次 PIR，通信量倍增。
JOIN / 聚合：PIR 只返回原始行，不做计算，要自己在客户端合并。

因此 PIR 典型应用是密钥交换、密码泄漏检查、证书透明日志查询、广告匿名定向——而不是关系数据库的通用查询。Google Chrome 的 Password Checkup、Signal 的 contact discovery、Meta 的 Private Computation 都用了 PIR 变体。

另一个常被忽略的问题是 PIR 的更新。朴素 PIR 假设数据库是静态的——每次数据变更都要重新预处理。Doerner 等（S&P 2020）给出了可更新 PIR 的初步方案，但开销仍然显著。在”每秒几十次写入”的数据库语境下，目前的 PIR 方案几乎都假设离线构建 + 定期重建，而不是在线更新。这对业务接入方式有直接影响：PIR 通常服务于”每日 / 每周批量发布”的只读目录，而不是在线 OLTP。

3.4 SealPIR / Spiral 的最小用法

OpenMined、Microsoft 等都开源了 SealPIR / Spiral 的实现。典型流程：

# 客户端
query = client.build_query(index=12345)
serialized = query.to_bytes()

# 服务器
ciphertext_response = server.process(serialized, database)

# 客户端
record = client.decode(ciphertext_response)

接口极简，工程上的难点是：数据库布局（按 PIR 要求 pad 到 \(n^{1/d}\) 的倍数）与吞吐（服务器端 NTT / 内积是 CPU 密集，需要向量化 + 多线程）。实际生产规模 ~10^6 条记录 × KB 级可以接受，再大就要分片。

另一个需要注意的点是查询模式的匿名性。PIR 只保证”服务端不知道查了哪一条”，但它不隐藏”查询频率”——如果某个用户一天查 10 次、另一个用户一天查 1000 次，服务端可以据此对用户做 traffic analysis。真实匿名系统（Tor over PIR 之类）要额外加 cover traffic 或批处理，这又把系统复杂度抬上来。所以 PIR 工程化的一句口诀是：PIR 解决的是”查什么”的匿名性，不是”谁在查”的匿名性。

四、哪些查询形态在当前开销下可行

4.1 可行 / 不可行的经验规则

把前面四条路线（FHE、洋葱加密、SE、PIR）合并看，一张”加密查询可行性矩阵”：

查询形态	TEE	DP	FHE	CryptDB	SE	PIR
等值点查	可行	可行	勉强	可行	可行	可行
范围查询	可行	可行	慢	可行（OPE）	部分	多次组合
LIKE / 全文搜索	可行	低精度	不可行	不支持	专用 SE	不支持
聚合（SUM / COUNT）	可行	可行	可行	可行（HOM）	不支持	不支持
JOIN	可行	可行（受限）	不可行	可行（DET）	不支持	不支持
复杂 OLAP	可行	可行	几乎不可行	可行（DET+OPE）	不支持	不支持
ML 推理	可行	训练侧	主流场景	不支持	不支持	不支持

一条经验规则：点查 yes、join no。任何需要”跨多条记录比较”或”基数 > 1000 的组合”的查询，纯密码学（FHE / PIR）都做不动；必须要么退化到 TEE，要么退化到”在明文上索引，在密文上取值”的混合方案。

更深一层的原因是：加密计算的代价与”跨记录依赖”成指数关系。单条记录内的运算（解密一个字段、推理一条向量）只是常数倍开销；一旦运算跨多条记录（JOIN、聚合、排序），密文空间里表达这种依赖的唯一办法是增加乘法深度，而乘法深度是 FHE 最贵的资源。这个事实在短期内不会改变，所以”混合架构”才是长期合理的形态——用 TEE 承担跨记录逻辑，用 FHE / PIR 保护单记录敏感字段。

4.2 性能开销量级

给一张 2026 年的参考数字（与同规模明文相比）：

场景	开销倍数
Always Encrypted（等值 / 范围）	1.1× ~ 3×
CryptDB Onion（混合）	1.1× ~ 2×
FHE 加密聚合（BFV / CKKS）	10× ~ 100×
FHE 加密 ML 推理	100× ~ 1000×
Spiral PIR（1M 行点查）	数秒延迟（绝对值，不是倍数）
纯 FHE SQL 执行	10^4× 以上（不实用）

读这张表的方式：倍数不是唯一维度。PIR / FHE 的”开销”很大一部分是固定延迟而非倍数，因此它们在小规模场景的相对劣势比大规模更显著。反过来说，大规模场景里 PIR 的绝对延迟也不会爆炸到不可用。

五、工程落地：银行与医疗的真实模式

5.1 银行的三个典型场景

银行业对加密查询的需求几乎是最强烈的，但现实采用的方案并不是”上 FHE”。典型模式：

跨境客户信息查询：境外分行要检查某客户是否在本国反洗钱黑名单。不能直接传客户 ID。
- 实现：客户端哈希 + 服务端 SSE 倒排索引；或小规模 PSI。
- 开销：毫秒到百毫秒级。
联合风控建模：几家银行联合跑欺诈模型，不交换明细。
- 实现：联邦学习 + TEE（Nitro Enclaves / TDX）；或同态加密 + PSI。
- 开销：训练一次几小时，可接受。
客户账户余额 / 交易聚合：客户隔离，内部分析师看不到单客户明细。
- 实现：列级加密（Always Encrypted）+ DP 发布。
- 开销：接近明文。

整体模式是 TEE 做日常 OLTP、DP 做内部分析、FHE / PIR 做跨机构协作。真正的全 FHE 数据库至今没有在任何大型银行的核心系统上线。

额外值得一提的是监管机构的态度：中国央行 2023 年发布的《金融数据安全分级指南》（JR/T 0197）、欧洲央行 2024 年的数字欧元技术规范，都把”加密计算”列为推荐手段，但并未强制特定算法。这给了银行选型的自由，也意味着没有哪种方案能凭监管红利一夜胜出——最终仍然是工程可行性说话。

5.2 医疗场景

医疗行业对”个人可识别信息（PII）“极度敏感，加上 HIPAA 的合规压力，是 FHE / SE 产品厂家最积极推广的领域。但落地同样受限：

基因组比对：基因序列长、计算密集，FHE 成本高，通常走 TEE + 本地预处理。少数特定场景（SNP 匹配）在 CKKS 下可以做，研究论文在 BMC Medical Informatics 等期刊里能找到。
影像诊断推理：CKKS 在图像卷积网络上可行，但对大模型仍然过贵，主流走 TEE。IBM、MSR 的 POC 显示 ResNet-32 级别的 FHE 推理需要分钟级延迟，对线上诊断是不可接受的。
流行病学聚合统计：DP + 联邦聚合最合适。欧美的新冠期间轨迹追踪基本用这条路。Apple / Google Exposure Notification 是规模最大的一次真实部署。
病历全文搜索：SE 有限 POC，产品化极少。多机构临床试验的数据交换更常用 TEE + 脱敏。

作者接触过的医疗客户通常走”三明治”：客户端加密 → TEE 内部解密计算 → 输出前 DP 加噪。纯密码学方案在这里基本是加分项，不是主力。这也侧面说明了一件事：合规压力大的行业，反而是最早接受”组合方案”的——它们没有选择的奢侈，只能把能用的手段全部组合起来。

5.3 广告与跨机构数据协作

广告行业是 PIR / PSI / FHE 当前最活跃的应用场景。Google Privacy Sandbox、Apple SKAdNetwork、Meta Private Computation 都是例子。核心需求：两方（广告主 vs 平台）各自持有用户数据，希望联合做转化归因，但不交换个人信息。

典型技术栈：

PSI：求用户交集（点击者 ∩ 购买者），用 FHE-based 或 OPRF-based 实现；
聚合（Secure Aggregation）：交集人数、转化金额上 DP 或 MPC（Secure Multi-Party Computation）；
Clean Room：数据托管到可信第三方（如 AWS Clean Rooms、Snowflake Clean Rooms），内部用 TEE + DP 混合。

跨机构协作是目前纯密码学方案跑得最接近主流的领域。原因之一：数据规模通常不大（百万到千万量级），PIR / PSI 的绝对延迟可以接受；原因之二：合规压力直接对应钱（欧盟 GDPR 罚款最高 4% 全球营收）。

5.4 落地建议

把本节提炼成几条具体建议：

不要从 FHE 开始。除非是密码组的研究项目，业务场景应当先考察 TEE / DP / CryptDB 能否满足，把 FHE 留作”最后兜底”。
把加密计算当成链路的一段，不是全部。几乎所有成功落地的系统都是多种技术组合：客户端加密 + TEE 中间计算 + DP 输出。
关注参数审查。FHE / PIR 的安全性依赖参数选择（LWE 维度、错误分布），错了就是 0 安全。务必对照 Homomorphic Encryption Standardization 等社区参数表。
准备”加密可观测性”。密文通信 / 密文计算的监控要绕过传统 APM，需要设计专门的 metric（错误率、noise budget 使用率、解密失败率）。
法务与密码学工程师要早对齐。合规要求往往定义了”攻击者能力”，这决定选哪种方案。例如”防内部 DBA”和”防国家级攻击者”需要的方案差得很远。

六、开放问题与路线判断

6.1 开放问题

高效 FHE bootstrap。CKKS bootstrap 仍在秒级，GPU / ASIC 加速（Intel HERACLES、Nvidia cuFHE）正在路上，但距离”毫秒级”还有一个数量级。
PIR 的多列索引。当前 PIR 默认按行号索引，真实 SQL 查询要按次级键（二级索引）查找，还没有公认的 PIR-friendly 索引结构。
可编程 FHE 编译器。把 SQL / Python 自动编译到 FHE 电路，让应用工程师不用写密文算子。Microsoft EVA、Google Transpiler、Zama Concrete ML 是初步尝试。
Post-Quantum PIR / FHE。FHE 本身基于格假设（LWE/RLWE），天然抗量子；但 PIR 中的某些变体仍依赖 DDH，需要迁移。
密文数据湖。Iceberg / Delta Lake 等开源表格式尚未考虑”密文优先”的存储格式，未来可能出现”加密列式存储”标准。

6.2 路线判断

FHE 短期内不会成为通用 SQL 引擎。它会继续在 ML 推理、加密聚合、PSI 这些细分赛道落地，但”全 FHE 数据库”不是 2030 前的现实目标。
PIR 会在反欺诈 / 证书透明 / 密码泄漏等场景标准化。这些场景数据规模适配 PIR，合规压力大，已经在走产品化。
洋葱加密 + TEE 兜底是最主流的”加密数据库”形态。几乎所有国产 CipherDB、金融密态数据库都是这个路线。
硬件加速决定未来 5 年节奏。Intel HERACLES、Nvidia cuFHE、专用 FHE 加速卡进入数据中心后，FHE 成本可能再降一个数量级，才有机会向更多查询形态渗透。
标准化滞后于工程。HomomorphicEncryption.org 的参数标准、ISO/IEC 18033-6 的同态加密标准（目前仍为 CD 阶段，待核实最新进度）都还在演进；数据库工程师需要做好”两年后迁移参数”的预案。
FHE + TEE 的”双保险”正在成为高敏感场景的默认模式。TEE 负责对抗边信道，FHE 负责即使 TEE 被攻破也不泄漏数据——两者合起来，才能给出满足未来 10 年合规要求的稳健架构。

七、小结

加密查询是个”理论好看、工程很难”的领域。二十年的研究把 FHE 从”每次乘法要几小时”压到”每秒数千次”；把 PIR 从”必须传 1 GB”压到”14 KB + 秒级”。但距离”任意 SQL 都能在密文上跑”，仍然差至少一个数量级——而且很可能永远达不到。这个”永远达不到”并不悲观：它只是提醒我们，密码学的目标从来不是替代数据库，而是补齐数据库的信任边界。

把本文压成三条带走：

加密查询不是一把刀，是一套工具箱：FHE / CryptDB / SE / PIR 各解决不同形态。先想清楚查询形态，再选方案。
纯密码学方案的真实位置是”点查 yes、join no”：聚合、ML 推理、PSI、主键 PIR 已经可用；复杂 OLAP 仍需 TEE 兜底。
隐私计算的胜利形态是组合：TEE + DP + FHE + PSI 的组合系统在银行、医疗、广告已经有生产级案例，纯 FHE 数据库至今不是。

本系列的”隐私三连”到此结束。回头看 TEE 数据库 / 差分隐私 / 本篇，三条路对应三种信任假设：信任硬件、信任聚合、谁都不信。真实工程里总是三种混用——就像分布式系统里”最终一致性 / 线性一致性 / 外部一致性”并存一样，没有单点解。下一篇切换视角，进入分布式系统理论的 CRDT 与 CALM 定理，讨论的是完全不同的一类”无协调可能性”问题。

参考文献

Rivest R., Adleman L., Dertouzos M. On Data Banks and Privacy Homomorphisms. Foundations of Secure Computation, 1978.
Gentry C. Fully Homomorphic Encryption Using Ideal Lattices. STOC 2009.
Brakerski Z., Gentry C., Vaikuntanathan V. (Leveled) Fully Homomorphic Encryption without Bootstrapping. ITCS 2012.
Fan J., Vercauteren F. Somewhat Practical Fully Homomorphic Encryption. IACR ePrint 2012/144.
Cheon J. H., Kim A., Kim M., Song Y. Homomorphic Encryption for Arithmetic of Approximate Numbers (CKKS). ASIACRYPT 2017.
Chillotti I., Gama N., Georgieva M., Izabachène M. TFHE: Fast Fully Homomorphic Encryption over the Torus. Journal of Cryptology, 2020.
Microsoft Research. Microsoft SEAL Library. https://github.com/microsoft/SEAL
OpenFHE Community. OpenFHE: Open-Source Fully Homomorphic Encryption Library. https://github.com/openfheorg/openfhe-development
Popa R. A., Redfield C. M. S., Zeldovich N., Balakrishnan H. CryptDB: Protecting Confidentiality with Encrypted Query Processing. SOSP 2011.
Naveed M., Kamara S., Wright C. V. Inference Attacks on Property-Preserving Encrypted Databases. CCS 2015.
Song D., Wagner D., Perrig A. Practical Techniques for Searches on Encrypted Data. IEEE S&P 2000.
Curtmola R., Garay J., Kamara S., Ostrovsky R. Searchable Symmetric Encryption: Improved Definitions and Efficient Constructions. CCS 2006.
Chor B., Goldreich O., Kushilevitz E., Sudan M. Private Information Retrieval. FOCS 1995.
Angel S., Chen H., Laine K., Setty S. PIR with Compressed Queries and Amortized Query Processing (SealPIR). IEEE S&P 2018.
Mughees M. H., Chen H., Ren L. OnionPIR: Response Efficient Single-Server PIR. CCS 2021.
Menon S. J., Wu D. J. Spiral: Fast, High-Rate Single-Server PIR via FHE Composition. IEEE S&P 2022.
Homomorphic Encryption Standardization Consortium. Homomorphic Encryption Security Standard. https://homomorphicencryption.org/

上一篇：【数据库研究前沿】差分隐私数据库：PINQ、APEx 到生产级 DP-SQL

下一篇：【数据库研究前沿】CRDT 与 CALM 定理：无协调系统的可能与不可能

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-08 · cryptography