全同态加密工程实践：从理论圣杯到生产落地的距离有多远

密码学 · 2026-06-09 · 19 阅读

前言

2009 年，Gentry 提出了第一个全同态加密（Fully Homomorphic Encryption, FHE）构造，解决了密码学领域几十年的公开问题。理论上，FHE 允许对密文直接执行任意计算，结果解密后与明文计算完全一致——这意味着数据在整个生命周期（存储、传输、计算）中始终处于加密状态。

然而从理论到生产落地，中间隔着一道巨大的工程鸿沟。一个朴素的 FHE 程序比明文计算慢约 100 万倍。经过 15 年的算法优化和工程改进，这个数字已经缩减到 100-1000 倍，但仍然是大多数场景无法接受的开销。

2025-2026 年，几件事同时发生了变化：

Intel 展示了 Heracles 芯片——3nm 专用 FHE 加速器，比 Xeon CPU 快 1000-5000 倍
NVIDIA 推出 cuFHE 库——在 GPU 上实现 FHE 加速
蚂蚁集团在 GPU 上实现 FHE 加速，在相关领域发表了多篇学术论文（具体数量因统计口径不同可能有差异，建议以蚂蚁集团技术博客公开信息为准）
隐私计算市场规模预计 2025 年达到百亿元人民币（中国信通院数据）

这些信号表明：FHE 正在从学术论文走向工程实践。

本文从工程师视角回答一个核心问题：在今天的技术条件下，FHE 能用在哪些场景？怎么用？

三种主流方案：选型决定一切

FHE 不是单一算法，而是一族方案。目前工程实践中主流的有三大类，选错方案意味着性能差 10 倍以上或功能不满足需求。

CODE

┌─────────────┬──────────────────┬──────────────────┬──────────────────┐
│             │      BFV/BGV     │      CKKS        │      TFHE        │
├─────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 计算类型     │ 精确整数运算      │ 近似浮点运算      │ 逐位/逐门运算     │
│ 典型场景     │ 数据库查询、投票   │ ML 推理、统计     │ 布尔电路、比较    │
│ 密文膨胀     │ 中等              │ 中等              │ 较大             │
│ 自举开销     │ 较重              │ 较重              │ 极轻（核心优势）  │
│ 批处理       │ SIMD 批处理优秀   │ SIMD 批处理优秀   │ 不支持批处理      │
│ 参数复杂度   │ 高               │ 高               │ 极高             │
│ 代表库       │ SEAL, HElib     │ SEAL, Lattigo    │ Concrete, TFHE-rs│
└─────────────┴──────────────────┴──────────────────┴──────────────────┘

选型原则：

需要精确整数运算（如数据库 COUNT/SUM、电子投票）→ BFV
需要浮点近似计算（如机器学习推理、统计分析）→ CKKS
需要快速的逐位操作（如字符串匹配、条件分支、比较器）→ TFHE
需要快速自举（深度电路、多次乘法链）→ TFHE

⚠️ 常见错误：很多教程用 CKKS 做整数计算，结果出现精度丢失。CKKS 是近似方案，小数部分会有噪声累积。整数计算必须用 BFV。

用 Python 跑起来：CKKS 方案实战

微软的 Microsoft SEAL 是目前最成熟的 FHE 开源库，C++ 实现，提供 Python 绑定。以下示例展示 CKKS 方案的完整流程。

环境准备

BASH

# 安装 SEAL Python 绑定
pip install seal-python  # 社区维护的 pybind11 绑定
# 或者使用 TenSEAL（更高层的封装，集成 TenSEAL 上下文）
pip install tenseal

版本说明：本文代码基于 tenseal >= 0.3.0 的 API 编写。tenseal 的 API 在 0.3 版本有过较大调整，如果你使用的是更早的版本（如 0.2.x），ts.context() 的参数传递方式可能不同。建议运行 pip install tenseal>=0.3.0 确保兼容。如果安装失败，可以改用 tenseal，它提供了更友好的 Python API 且底层同样基于 SEAL。

示例：加密状态下的平均值计算

PYTHON

"""
CKKS 方案实战：加密数据计算平均值
场景：多个部门各自持有薪资数据，需要计算整体平均值而不泄露各自数据
依赖：pip install tenseal
"""
import tenseal as ts

# ============================================================
# 1. 上下文配置（决定安全级别和计算能力的核心参数）
# ============================================================
# poly_modulus_degree: 多项式模数度，越大越安全但越慢
# coeff_mod_bit_sizes: 系数模数位数链，决定乘法深度
# 8192 对应约 128-bit 安全级别，最多支持 2 层乘法
context = ts.context(
    ts.SCHEME_TYPE.CKKS,
    poly_modulus_degree=8192,
    coeff_mod_bit_sizes=[60, 40, 40, 60]
)
context.generate_galois_keys()
context.global_scale = 2**40  # 缩放因子，控制精度

# ============================================================
# 2. 加密数据
# ============================================================
# 部门 A 的薪资数据（单位：万元）
dept_a_salaries = [15.2, 18.7, 22.3, 25.0, 30.5]
# 部门 B 的薪资数据
dept_b_salaries = [12.8, 16.5, 20.1, 28.3, 35.0, 40.2]

enc_a = ts.ckks_vector(context, dept_a_salaries)
enc_b = ts.ckks_vector(context, dept_b_salaries)

print(f"部门 A 加密数据大小: {enc_a.size()} 个密文槽")
print(f"部门 B 加密数据大小: {enc_b.size()} 个密文槽")

# ============================================================
# 3. 在密文上计算（无需解密！）
# ============================================================
# 计算总人数
n_a = enc_a.size()
n_b = enc_b.size()

# 计算部门 A 的薪资总和
sum_a = enc_a.sum()
# 计算部门 B 的薪资总和
sum_b = enc_b.sum()

# 计算整体总和（密文加法）
total_sum = sum_a + sum_b
# 计算总人数
total_count = n_a + n_b

# 计算平均值（密文 × 明文除法）
# CKKS 不直接支持密文除法，用乘倒数代替
avg = total_sum * (1.0 / total_count)

# ============================================================
# 4. 解密验证
# ============================================================
result = avg.decrypt()
actual_avg = sum(dept_a_salaries + dept_b_salaries) / (len(dept_a_salaries) + len(dept_b_salaries))

print(f"\n加密计算的平均值: {result[0]:.4f}")
print(f"明文计算的平均值:   {actual_avg:.4f}")
print(f"误差:             {abs(result[0] - actual_avg):.6f}")

参数调优的关键陷阱

上面的代码能跑，但参数选择直接影响安全性和性能。以下是工程师必须理解的三个核心参数：

1. poly_modulus_degree（多项式模数度）

值	安全级别	性能	适用场景
4096	≈80-bit	最快	仅测试，不用于生产
8192	≈128-bit	快	大多数场景的默认选择
16384	≈192-bit	中等	高安全需求
32768	≈256-bit	慢	极高安全需求

2. coeff_mod_bit_sizes（系数模数链）

这条链的长度决定了能做的乘法深度。每次乘法消耗链中的一项，用完就不能再乘了：

PYTHON

# 只做 1 次乘法（如单次加法后乘系数）
coeff_mod_bit_sizes=[60, 40, 60]  # 3 个元素 = 1 层乘法

# 做 3 次乘法（如多项式求值）
coeff_mod_bit_sizes=[60, 40, 40, 40, 60]  # 5 个元素 = 2 层乘法

# 做 8 次乘法（如浅层神经网络推理）
coeff_mod_bit_sizes=[60, 40, 40, 40, 40, 40, 40, 40, 60]  # 9 个元素 = 4 层乘法

⚠️ 常见错误：coeff_mod_bit_sizes 的首尾两项之和不能超过 poly_modulus_degree 对应的密文模数限制。如果遇到 "encryption parameters are not valid" 错误，通常是这个约束不满足。

3. global_scale（缩放因子）

CKKS 是近似方案，浮点数被编码为整数后乘以 scale。scale 越大，精度越高，但留给乘法的模数空间越小。经验法则：

CODE

scale_bits + max_coeff_bits ≤ poly_modulus_degree × log2(plain_modulus_bits)

性能现实：到底有多慢？

2026 年的典型性能数据（基于公开基准测试，8192 参数，128-bit 安全）：

CODE

┌────────────────────┬──────────────┬──────────────┬───────────────┐
│ 操作               │ BFV (SEAL)   │ CKKS (SEAL)  │ TFHE (concrete)│
├────────────────────┼──────────────┼──────────────┼───────────────┤
│ 加密 1 个整数      │ ~0.5 ms      │ ~0.5 ms      │ ~15 ms/比特   │
│ 密文加法           │ ~0.01 ms     │ ~0.01 ms     │ ~0.005 ms     │
│ 密文 × 明文        │ ~0.1 ms      │ ~0.1 ms      │ ~0.01 ms      │
│ 密文 × 密文        │ ~5 ms        │ ~5 ms        │ ~2 ms         │
│ 自举（Bootstrapping）│ ~200 ms     │ ~200 ms      │ ~0.5 ms       │
│ 密文大小 (每个值)   │ ~100 KB      │ ~100 KB      │ ~50 KB        │
└────────────────────┴──────────────┴──────────────┴───────────────┘

数据来源说明：以下数据为量级估算值，综合参考了 Microsoft SEAL 官方 benchmark、Zama Concrete 文档、IBM HElib 公开性能测试。具体数值受 CPU 型号、内存带宽、参数配置影响较大，仅供选型参考。 建议在实际部署前，针对目标场景使用对应库的官方 benchmark 工具（如 seal-benchmark）在目标硬件上进行实测。单线程 CPU 参考值。

关键观察：

加法几乎免费：同态加法的开销与明文相当
乘法是瓶颈：密文 × 密文比明文慢 1000-5000 倍
自举是核心差异：TFHE 的自举比 BFV/CKKS 快 400 倍，这是它在大深度电路中的杀手锏

硬件加速：从 100 万倍到 100 倍

Intel Heracles：专用芯片的力量

2025 年，Intel 展示了 Heracles FHE 加速器（IEEE 论文，具体加速比因操作类型和对比基线不同而有差异）：

工艺：3nm
频率：1.2 GHz
性能：关键 FHE 操作比 Xeon CPU 快数个数量级（Intel 官方宣称 1000-5000 倍范围，具体取决于对比的 CPU 型号和操作类型）
内存：48 GB HBM，8192 GB/s 带宽
起源：DARPA DPRIVE 计划，2020 年启动

Heracles 的核心创新不是简单的并行化，而是针对 FHE 内存访问模式的架构优化。FHE 的计算瓶颈不在算术逻辑，而在于大量的多项式系数重排（Number Theoretic Transform, NTT）。Heracles 设计了专用的 NTT 数据路由网络，消除了传统 CPU/GPU 上的内存墙问题。

GPU 加速：NVIDIA cuFHE

NVIDIA 的 cuFHE 库在 GPU 上实现了 FHE 加速，利用 GPU 的大规模并行能力处理 NTT 变换。蚂蚁集团的实践（见参考来源 7）表明，GPU 加速 FHE 在批量推理场景下可获得显著加速，且可以复用企业已有的 GPU 基础设施（不需要采购专用硬件）。

说明：以下加速比为量级估算，实际效果受数据规模、参数配置、内存带宽等多因素影响。建议以各方案的官方 benchmark 数据为准。

加速效果对比

CODE

┌─────────────────────┬────────────────┬────────────────┬────────────────┐
│ 方案                │ 相对 CPU 加速   │ 适用阶段        │ 成本           │
├─────────────────────┼────────────────┼────────────────┼────────────────┤
│ CPU (SEAL 单线程)    │ 1× (基线)      │ 原型开发        │ 低             │
│ CPU (SEAL + OpenMP) │ 4-8×          │ 中小规模部署    │ 低             │
│ GPU (cuFHE)         │ 100-500×      │ 批量推理        │ 中（需 GPU）   │
│ FPGA                │ 50-200×       │ 定制化场景      │ 中高           │
│ ASIC (Heracles)      │ 1000-5000×   │ 大规模部署      │ 高（量产成本低）│
└─────────────────────┴────────────────┴────────────────┴────────────────┘

生产落地的三个可行场景

基于当前性能水平，以下三个场景已经具有工程可行性：

场景 1：隐私集合求交（PSI）

两个机构需要找出共同用户，但不暴露各自的全量用户列表。使用 BFV 方案，将用户 ID 编码为整数，加密后通过同态运算计算交集。

实际案例：隐私集合求交在广告归因、医疗数据联合分析等场景有大量应用。Google 在其 Private Join and Compute 开源项目中实现了基于 PSI 的隐私统计方案，可供参考。此外，OpenMined 项目的 PSI 协议也是业界广泛使用的参考实现。

场景 2：加密数据库查询

将数据库字段加密后存储，客户端发送加密查询条件，服务器在密文上执行查询并返回加密结果。

技术要点：

使用 BFV 做等值比较（密文 × 密文 = 0 表示相等）
使用 TFHE 做范围比较（逐位比较布尔电路）
返回结果需要客户端解密

场景 3：隐私机器学习推理

模型提供方加密模型参数，数据提供方加密输入数据，双方在密文上执行推理，只返回加密结果。

当前瓶颈：深度神经网络的自举需求极高。一个 10 层的 CNN 可能需要数百次自举操作，即使使用 TFHE 也需要数分钟。浅层模型（≤5 层）更现实。

工程实践中的五个坑

坑 1：密文膨胀

CKKS 方案的密文膨胀率约为 1000 倍。一个 32-bit 整数加密后变成约 100 KB 的密文。这意味着：

存储成本增加 1000 倍
网络传输延迟大幅增加
对策：使用 SEAL 的 save/load 压缩功能，可减少 50-70% 的存储

坑 2：噪声管理

CKKS 方案中每次乘法都会增加噪声。当噪声超过阈值时，解密结果将出错。工程师需要：

精确计算乘法深度，预留足够的 coeff_mod 预算
在适当位置执行自举（Bootstrapping）清除噪声
使用 context.last_parms_id() 监控当前噪声水平

坑 3：参数兼容性

SEAL 的加密参数必须完全匹配才能进行运算。生产环境中，不同版本的 SEAL 库可能使用不同的默认参数。最佳实践：将序列化的 context 与密文一起存储，而不是依赖默认参数。

坑 4：密钥管理复杂度

FHE 方案的密钥体系比传统加密复杂得多：

CODE

Secret Key (私钥)     → 解密用，绝对不能共享
Public Key (公钥)      → 加密用，可以共享
Relinearization Key    → 密文乘法后压缩密文大小
Galois Key             → 密文旋转（SIMD 槽位操作）

密钥的存储、轮换、销毁需要专门设计，不能简单套用传统 PKI 的流程。

坑 5：调试困难

加密后的数据无法直接查看，调试 FHE 程序极其痛苦。建议：

先用明文模拟验证算法逻辑
使用 SEAL 的 print_parameters() 检查参数
在关键位置插入"解密检查点"（开发环境专用）
使用 tenseal 的 plain_tensor 对比中间结果

国密体系下的 FHE 定位

FHE 基于格密码（Lattice-based Cryptography），而我国国密体系以 SM2（椭圆曲线）/SM4（分组密码）为主。两者不是替代关系，而是互补关系——FHE 解决的是"数据可用不可见"的计算层问题，国密解决的是"数据在传输和存储中的保密性"问题。

1. 密评合规中的 FHE 定位

在等保 2.0 和密评（GB/T 39786-2021《信息安全技术信息系统密码应用基本要求》）框架下，数据处理环节的安全要求日益严格。GM/T 0054-2018 中关于"数据完整性"和"数据保密性"的要求，可以通过以下方式与 FHE 结合：

数据存储层：使用 SM4 加密静态数据（满足密评对存储加密的要求）
数据传输层：使用 SM2 进行密钥交换和通信加密（满足密评对传输加密的要求）
数据计算层：使用 FHE 对密文进行计算，实现"数据可用不可见"（满足数据安全法中关于数据利用与保护并重的原则）

这种分层架构的好处是：每一层都使用经过密评认证的成熟方案（SM2/SM4），同时通过 FHE 在计算层实现更高水平的数据保护。

2. 后量子迁移的协同效应

SM2 基于椭圆曲线离散对数问题（ECDLP），会被 Shor 算法完全破解。FHE 所基于的格密码（LWE/RLWE 问题）目前被认为对量子计算具有抗性。这意味着：

在规划后量子迁移路径时，FHE 可以作为"一石二鸟"的方案——既解决隐私计算需求，又为后量子安全做准备
格密码的标准化工作（如 NIST PQC 中的 ML-KEM/ML-DSA）与 FHE 的数学基础高度相关，投入 FHE 的团队在后量子迁移时会更有技术储备

3. 标准化现状与建议

目前 GM/T 标准体系中尚无专门针对 FHE 的标准。但以下工作值得关注：

全国密码标准化技术委员会正在跟踪 ISO/IEC 18033（加密算法国际标准）中同态加密相关的工作
在密评实践中，FHE 作为增强性安全措施（非强制性要求），可以在密评报告的"增强安全措施"部分进行说明
建议在涉及 FHE 的项目中，提前与密评机构沟通技术方案的认可范围

注意：以上分析基于公开标准的技术解读。在实际密评项目中，FHE 作为新技术是否被认可需要咨询具体的密评机构。建议以现行有效的 GM/T 标准文本为准。

总结

全同态加密正处在一个关键转折点：

算法成熟：BFV/CKKS/TFHE 三大方案各有适用场景，工程师可以根据需求选型
性能突破：硬件加速将 FHE 从"理论可行"推向"工程可用"，1000-5000 倍加速意味着实际开销可降至 10-100 倍
生态完善：Microsoft SEAL、Zama Concrete/TFHE-rs、OpenFHE 等开源库大幅降低了开发门槛
场景明确：隐私集合求交、加密数据库查询、隐私机器学习推理是三个已经具有落地条件的场景

对于工程师来说，现在正是投入 FHE 学习的最佳时机。当 Intel Heracles 这样的专用芯片量产部署时，FHE 将从"能用但贵"变成"好用且值得"。

参考来源

Microsoft SEAL - https://github.com/microsoft/SEAL
TenSEAL (Python CKKS wrapper) - https://github.com/OpenMined/TenSEAL
Zama Concrete (TFHE Python) - https://github.com/zama-ai/concrete
Intel Heracles FHE Accelerator - IEEE Spectrum, 2025（参见 Intel Labs 公开技术报告及 IEEE 论文）
BGV/BFV/CKKS 方案对比 - 腾讯云《同态加密：实现数据的可算不可见》- https://cloud.tencent.com/developer/article/2274458
南京大学《同态加密在深度学习中的应用综述》- https://ai.nju.edu.cn/rinc/publish/download/2024/2024YHZttjm.pdf
蚂蚁集团 FHE GPU 加速 - InfoQ《最极致的数据安全计算》- https://www.infoq.cn/article/sjlgGt1p4xvaWWgGgRrZ
GM/T 0054-2018 信息系统密码应用基本要求 - 国家标准全文公开系统
中国信通院《隐私计算白皮书》- 2022
Intel DARPA DPRIVE 计划 - https://www.intel.com/content/www/us/en/newsroom/news/intel-darpa-drive-program.html
Google Private Join and Compute (PSI 开源实现) - https://github.com/google/private-join-and-compute
OpenMined PSI 协议 - https://github.com/OpenMined/PSI

全同态加密隐私计算 BFV CKKS TFHE

← 返回文章列表