全同态加密（FHE）深度解析：从 Gentry 奠基到生产级隐私计算

引言：密码学的"圣杯"

想象这样一个场景：你希望让云服务处理你的医疗记录，但又不希望云服务商看到任何明文数据。传统做法是你下载数据、解密、处理、加密、再上传。而全同态加密（Fully Homomorphic Encryption, FHE）承诺让这一切变得不同——你可以在不解密的情况下，直接对密文进行任意计算，得到的结果解密后等同于对明文做同样的计算。

这听起来像是魔法，但它确实是现代密码学中最深刻、最强大的构造之一。自 2009 年 Craig Gentry 提出第一个可行性方案以来，FHE 已从纯理论逐步走向工程实践，在隐私计算、联邦学习、机密云计算、基因组分析等领域展现出巨大的应用潜力。

本文将从最基础的问题出发，系统梳理 FHE 的数学原理、方案演进、工程实现与未来方向，帮助你构建完整的认知框架。

一、从部分同态到全同态：问题的演进

1.1 什么是同态加密？

同态加密的核心性质可以用一个简洁的公式表达：

Dec(Enc(a) ⊙ Enc(b)) = a ⊕ b

其中 ⊕ 和 ⊙ 分别是明文空间和密文空间上的运算。这意味着在密文上执行某类操作后，解密结果等同于在明文上直接执行另一类操作。

1.2 部分同态加密（PHE）

许多经典加密方案天然具备某种同态性质：

方案	支持的运算	典型用途
RSA（无填充）	乘法同态	数字签名、密钥交换
ElGamal	乘法同态	电子投票
Paillier	加法同态	隐私求和、电子投票
Benaloh	有限次加法	安全多方计算

Paillier 的加法同态性质最为实用：Enc(a) · Enc(b) = Enc(a + b)。例如在电子投票中，计票方可以在不知道每张选票内容的情况下，直接聚合所有密文选票，解密后得到总票数。

1.3 些许同态加密（SHE）

如果一种方案可以同时支持加法和乘法，但仅限有限次数，则称为些许同态加密（Somewhat Homomorphic Encryption）。Gentry 之前的方案（如 BGN、IPP 等）都属于这一类。

1.4 全同态加密（FHE）的突破

全同态加密 = 同时支持无限次加法和乘法。因为任意布尔电路都可以用 NAND（或 AND + XOR）门构成，而 NAND 可以由一次乘法和一次加法实现，所以支持无限次加法 + 乘法的方案就等价于支持任意计算。

2009 年，Craig Gentry 在斯坦福博士论文中首次构造出真正的 FHE 方案，这被称为密码学领域的"圣杯"终于被摘下。

二、Gentry 范式：Bootstrapping 的核心思想

2.1 噪声增长问题

所有实用的 FHE 方案都基于"近似特征向量"或"噪音"的思想：密文中包含一个可控的噪声项，解密时噪声会被消除。但每次同态运算（尤其乘法）都会增大噪声。当噪声超过阈值时，解密就会失败。

这正是 SHE 方案的局限——噪声增长限制了可执行的运算深度。

2.2 自举（Bootstrapping）

Gentry 的天才想法是：同态地执行解密操作，从而"刷新"密文、重置噪声水平。

具体而言，Bob 持有密文 c 和私钥 sk。他将私钥加密为 sk*（用自己公钥加密自己私钥），然后将 c 和 sk* 发送给 Alice。Alice 在不解密的情况下，用同态解密电路"消耗"掉噪声，输出一个同明文但噪声清零的新密文。

原始密文 c（噪声 = δ）
    ↓ [同态解密: Dec*(c, sk*)]
新密文 c'（噪声 ≈ δ₀，远小于 δ）

代价：自举本身开销很大。因此 Gentry 范式将 FHE 分解为两步——先用 SHE 支持有限次运算，再通过自举"续命"，实现无限次运算。

2.3 密钥交换与模交换（后续优化）

后来的研究对 Gentry 范式进行了大量优化：

• 密钥交换（Key Switching）：在不同密钥间转换密文，避免使用公钥加密私钥带来的巨大开销。
• 模交换（Modulus Switching）：Brakierski 和 Vaikuntanathan 发现通过缩小密文模数可以线性控制噪声增长，比自举更高效。这一发现是现代 FHE 方案（BGV、BFV）的基石。

三、四代 FHE 方案演进

3.1 Gentry 原始方案（2009）

基于理想格（Ideal Lattices）构造，安全性基于理想格上的近似最短向量问题（approx-SVP）和有界距离解码问题（BDD）。首次证明了 FHE 的存在性，但效率极低——一个比特同态运算需要 30 分钟。

3.2 BGV 方案（Brakerski-Gentry-Vaikuntanathan, 2011）

第一个不再依赖 Gentry 原始构造的方案。核心创新是模交换：每次乘法后通过缩小模数来控制噪声，使其保持在线性范围而非指数增长。自举变得不那么频繁，效率大幅提升。

BGV 基于 LWE（Learning With Errors）问题，安全性有广泛研究支持。

3.3 BFV 方案（Brakerski/Fan-Vercauteren, 2012）

与 BGV 类似但采用不同的噪声管理策略——在整数环上使用 BFV 的明文空间结构，支持精确的整数运算。对密码学中的精确计算（如比较、查表）更友好。

BFV 不依赖模交换，而是通过预计算来管理噪声。适合需要精确结果的场景。

3.4 GSW 与 FHEW/TFHE（2013-2016）

Gentry-Sahai-Waters (GSW) 方案基于近似特征向量问题，其关键突破是乘法运算中密文不膨胀（矩阵乘法保持固定维度）。

Chillotti 等人基于 GSW 提出了 TFHE（Fast Fully Homomorphic Encryption over the Torus），它的革命性之处在于：每个门（AND、OR、NOT、XOR）的同态运算只需约 10-30 毫秒！

TFHE 使用环面（R torus）上的 LWE 变体，支持高效的门自举（Gate Bootstrapping），特别适合需要逐位布尔电路计算的场景。

3.5 CKKS 方案（Cheon-Kim-Kim-Song, 2017）

CKKS 是迄今在近似计算领域最重要的 FHE 方案。它专门处理实数/复数向量，使用重缩放（Rescaling）替代模交换来管理噪声，非常适合机器学习推理、统计分析等近似计算场景。

CKKS 支持打包（Batching）：一个密文可以打包数千个值（SIMD 风格），计算时自然实现并行。

隐私机器学习推理（如 CrypTFHE、废密推理框架）大多基于 CKKS。

3.6 方案对比总览

方案	时间	基础问题	自举	最佳场景
Gentry '09	2009	理想格	每次门	理论存在性证明
BGV	2011	LWE/RLWE	每若干层	模运算、精确整数
BFV	2012	RLWE	每若干层	精确整数、字符串
TFHE	2016	TLWE/TRLWE	每个门（ms级）	布尔电路、通用门
CKKS	2017	RLWE	每若干层	机器学习、浮点近似

四、FHE 工程实现与工具链

4.1 主流 FHE 库

经过十多年发展，FHE 已有多个成熟的开源实现：

• Microsoft SEAL：微软研发，支持 BFV 和 CKKS。C++ 实现，有 .NET 和 Python 绑定。文档完善，社区活跃。
• OpenFHE：Google、MIT 等支持的 BGV/BFV/CKKS/TFHE/DM 全方案库，C++ 实现，是 PALISADE 的后继者。
• TFHE-rs：Zama 团队用 Rust 实现的高性能 TFHE 库，支持 WASM 目标，可部署到浏览器环境。
• Concrete：Zama 基于 TFHE-rs 的 Python 编译框架，让开发者用普通 Python 代码编写 FHE 程序并自动编译为 FHE 电路。
• Lattigo：EPFL 的 Go 语言实现，支持 BFV/CKKS/BGV，适合分布式场景。
• HElib：IBM 出品，基于 BGV 和 CKKS，历史悠久但已逐步被 OpenFHE 取代。

4.2 编程模型差异

FHE 编程与传统编程有本质区别：

// 传统代码
int x = a + b;
int y = x * c;

// FHE 代码 (伪代码 + SEAL)
Encryptor encryptor(context);
Encrypt(a_enc, a);  // 加密
Encrypt(b_enc, b);
Encryptoror(b_enc);

// 同态加法
EvalOror.add(a_enc, b_enc, add_enc);       // add_enc = a_enc + b_enc
// 同态乘法
EvalOror.multiply(add_enc, c_enc, mul_enc); // mul_enc = (a+b) * c
// 需要重线性化
EvalOror.relinearize(mul_enc, relin_keys, mul_enc);
// 解密
Decryptoror(mul_enc, result);

关键约束：

• 无分支：FHE 无法做条件跳转（否则泄露中间值信息），需用选择门替代 if-else。
• 无循环（控制次数）：循环次数必须静态确定，不能依赖密文。
• 噪声预算：每次乘法消耗一部分"噪声预算"，需合理规划电路深度或安排自举。

五、从理论到产业：真实应用案例

5.1 iDASH 基因组隐私竞赛

iDASH（Integrating Data for Analysis, Anonymization and SHaring）是国际著名的基因组隐私计算竞赛，多届主题直接聚焦 FHE：

• GWAS（全基因组关联分析）中的等位基因频率统计
• 基因组编辑效率的回归分析
• 加密字符串匹配（保护患者标识）

FHE 让多个医院可以协同计算基因组分析结果，但任何一方都无法获知其他机构的原始数据。

5.2 隐私机器学习推理

2016 的 CryptoNets 论文首次证明：用 FHE（基于 CKKS）可以在加密的 MNIST 图像上做推理，准确率仅下降 0.38%。

现代框架如 NGRAPH-HE、GAZELLE（混合 FHE + 混淆电路）、Delphi 等进一步将深度学习推理开销降低到可接受范围（秒级）。

典型场景：医院上传加密的医学影像模型推理请求，云端返回加密结果，全程不暴露图像或模型权重。

5.3 金融风控与合规

银行间需要联合评估客户信用风险，但不愿共享各自的客户数据。FHE 实现"可用不可见"：

• 多方各自加密特征数据
• 在密文上执行 XGBoost / 逻辑回归评分
• 返回加密评分结果

5.4 Apple 与 Google 的 FHE 部署

苹果在 iOS 中部署了基于 FHE 的 Photos 重复检测——在不解密的情况下识别用户照片库中的重复/相似图片。Google 在 Chrome 中也使用 FHE 进行密码检查（Pwned Passwords 服务），确保用户的密码不会以明文形式发送到服务器。

5.5 全同态加密即服务（FHE-as-a-Service）

Zama 推出了 fhEVM——一个支持 FHE 智能合约的 EVM 兼容链，允许在链上对加密状态执行任意计算。这是 FHE 与区块链结合的重要里程碑。

IBM FHE Toolkit 提供 Docker 化部署方案，包含 iOS/macOS 和 Linux SDK，内置加密健康记录、金融转账等示例应用。

六、挑战与代价：何时不该用 FHE

FHE 并非万能的银弹。了解其局限与正确使用时同样重要。

6.1 性能开销

操作	明文开销	FHE 开销	倍数
整数加法	<1 ns	~1 ms	~10⁶
整数乘法	~1 ns	~10 ms	~10⁷
浮点运算	~1 ns	~100 ms	~10⁸
比较操作	~1 ns	~10 ms+（TFHE）	~10⁷+

FHE 比明文慢 10⁵ 到 10⁸ 倍。这不是常数因子差距，而是跨数量级的差距。

6.2 密文膨胀

FHE 密文的大小远比明文膨胀。一个 32 位整数加密后可能膨胀到 512KB 到 2MB。CKKS 通过打包可以缓解，但仍比明文大 1000-10000 倍。

6.3 密钥管理复杂

FHE 方案需要管理多种密钥：公钥、私钥、重线性化密钥、自举密钥、 Galois 密钥（用于旋转）。自举密钥和 Galois 密钥可以达到数 GB，这是部署中的实际工程瓶颈。

6.4 何时不该用 FHE

• 非多方可信场景：如果只有一方持有数据，没有必要用 FHE，同态加密解决的是多方不信任问题。
• 简单数据查询：如果只需要搜索/比对，不需要 FHE 的全同态能力，PEKS、SSE 等可搜索加密更高效。
• 高频实时系统：FHE 的低频（秒级）特性使其不适合高频交易、实时音视频处理等场景。
• 可选择 TEE：如果硬件可信执行环境（Intel SGX/TDX、ARM TrustZone）可用且信任模型接受，TEE 通常比 FHE 快 10-100 倍。

七、前沿进展（2024-2026）

7.1 自举性能突破

Zama 团队在 TFHE-rs 中实现了 GPU 加速自举，单 GPU 每秒可处理约 10,000 次自举操作。CKKS 的自领性能也因数论变换（NTT）硬件加速而大幅提升。

7.2 FHE 硬件加速

DARPA DPRIVE 计划资助了多个 FHE 专用芯片项目：

• Intel HEXL：面向 AVX-512 的 FHE 加速库，NTT 运算加速 5-10 倍。
• Duality Technologies 的 FHE 加速器：基于 FPGA 的 CKKS 计算加速卡。
• 定制 ASIC 研究：Cornell、MIT 等正在研发 FHE 专用芯片，目标是将自举降到微秒级。

7.3 功能加密（Functional Encryption）融合

功能加密允许对特定函数集输出部分解密结果（如只输出均值而非原始数据）。结合 FHE 和功能加密的混合方案正在被研究，可以在某些场景下显著降低开销。

7.4 多方 FHE（Multi-Key FHE）

FHE 的多方版本（MKFHE）支持不同参与方使用各自密钥加密数据，并在这些密文上联合计算。这在多方数据协作场景中至关重要，技术挑战在于跨密钥计算时的噪声控制。

7.5 FHE 标准化

HomomorphicEncryption.org 联盟（包括 Intel、Microsoft、Google、IBM、MIT 等）正在推进 FHE 标准制定，预计在 2025-2026 年推出标准草案。标准化将极大促进 FHE 的互操作性和产业采用。

八、学习路线与上手建议

对希望深入 FHE 的读者，推荐以下分阶段学习路径：

阶段一：概念理解（1-2 周）

• 阅读 Gentry 原始论文（ACM CCR 版，精简版）
• 学习 LWE/RLWE 问题本质
• 理解 Bootstrapping 的核心思想

阶段二：动手实验（2-4 周）

• 安装 Microsoft SEAL 或 OpenFHE
• 完成官方示例（BFV 基本运算 → CKKS 打包计算）
• 尝试实现一个简单的加密统计（均值/方差）或加密整数比较

阶段三：深入专项（1-2 月）

• 选定方向：TFHE（布尔电路）、CKKS（近似计算）、BFV（精确整数）
• 阅读对应方案的教材/论文
• 实现一个完整的应用原型（如加密推理、加密数据库查询）

阶段四：前沿研究

• 跟踪 ePrint (eprint.iacr.org) 上的 FHE 论文
• 关注 HomomorphicEncryption.org 的标准动态
• 参加 iDASH 竞赛、FHE.org 社区

九、总结

全同态加密从 Gentry 2009 年的理论跨越，经过四代方案演进，正在从学术论文走向生产部署。尽管在性能上仍比明文慢多个数量级，但随着算法优化、硬件加速和标准化的推进，FHE 的适用边界正在不断扩展。

其核心价值可以用一句话概括：数据在使用过程中保持加密，信任边界从"人不看数据"变成"人无法看数据"。在隐私保护日益成为刚性需求的今天，掌握和理解 FHE，就是掌握了下一代可信计算的关键钥匙。

参考资料

• Craig Gentry, "Fully Homomorphic Encryption Using Ideal Lattices", STOC 2009
• Zvika Brakerski, Craig Gentry, Vinod Vaikuntanathan, "(Leveled) Fully Homomorphic Encryption without Bootstrapping", ITCS 2012
• Ilaria Chillotti et al., "TFHE: Fast Fully Homomorphic Encryption Over the TORUS", JoC 2020
• Jung Hee Cheon et al., "Homomorphic Encryption for Arithmetic of Approximate Numbers", ASIACRYPT 2017
• Microsoft SEAL: github.com/microsoft/SEAL
• OpenFHE: github.com/openfheorg/openfhe-development
• TFHE-rs: github.com/zama-ai/tfhe-rs
• HomomorphicEncryption.org 标准工作组