全同态加密(Fully Homomorphic Encryption, FHE)被誉为密码学的”圣杯”——它允许任何人对密文直接执行任意计算,而无需解密,计算结果解密后与对明文执行同样运算所得完全一致。自 2009 年 Gentry 提出第一个 FHE 方案以来,这一领域经历了四代方案的演进,正在从纯粹的理论构造走向可落地的工程实践。本文聚焦当前最活跃的前沿方向:TFHE 可编程自举(programmable bootstrapping)、多密钥 FHE、FHE 编译器与自动参数优化、FPGA/ASIC/GPU 硬件加速,以及 FHE 与多方计算(MPC)、零知识证明(ZKP)的混合架构。
一、FHE 的发展回顾与现状
先看一张图,把这一节的关键关系串起来。
graph TD
M[明文]
E[加密]
C[密文运算]
B[自举]
K[编译器]
H[硬件加速]
X[混合架构]
M --> E --> C --> B
C --> K --> H
C --> X
1.1 四代方案的演进
FHE 的发展可以清晰地划分为四代。第一代以 Gentry 2009 年基于理想格(ideal lattice)的方案为代表,其核心思路是”有些嘈杂的加密 + 自举(bootstrapping)“:每次同态运算后密文中的噪声会增长,当噪声即将淹没明文时,通过同态地执行解密电路来”刷新”噪声——这就是自举。第一代方案的自举需要”压缩解密电路”(squashing),效率极低。
第二代以 BGV(Brakerski-Gentry-Vaikuntanathan, 2012)和 BFV(Brakerski/Fan-Vercauteren)为代表,引入了模数切换(modulus switching)技术来管理噪声,使得在一定乘法深度内可以不执行自举,即”层级同态加密”(leveled FHE)。BGV/BFV 方案在处理整数批量运算(SIMD packing)方面表现优异,成为早期实用化探索的主力。
第三代以 GSW(Gentry-Sahai-Waters, 2013)为代表,采用近似特征向量(approximate eigenvector)的方法,将密文表示为矩阵,使得噪声增长变为非对称的——乘法中只有一个操作数的噪声会放大。这一特性使得自举电路大幅简化。
第四代则是当前最受关注的 CKKS(Cheon-Kim-Kim-Song, 2017)和 TFHE(Torus FHE, Chillotti-Gama-Georgieva-Izabachène, 2016-2020)。CKKS 支持对近似实数的同态运算,非常适合机器学习推理场景;TFHE 则以极快的自举速度著称——单次门自举(gate bootstrapping)仅需约 10 毫秒,这使得它成为逐位逻辑运算和非线性函数计算的首选方案。
1.2 当前实用化的主要障碍
尽管四代方案不断进步,FHE 距离广泛实用仍面临三大障碍。第一是性能开销:即便是最快的 TFHE 门自举,相比明文计算仍慢四到六个数量级;对于 CKKS/BFV 的多项式运算,密文膨胀率(ciphertext expansion ratio)通常在 10 倍至 1000 倍之间,传输与存储代价高昂。第二是编程难度:开发者必须理解噪声预算(noise budget)、参数选择、明文编码方式等底层细节,这与普通编程体验相去甚远。第三是缺乏统一标准:不同方案的安全假设、参数推荐、API 接口各不相同,互操作性差。正是这三大障碍催生了本文所讨论的各项前沿工作。
二、TFHE 可编程自举深度
2.1 环面表示与 TLWE/TGLWE
TFHE 的核心创新在于将明文和噪声嵌入环面(torus)\(\mathbb{T} = \mathbb{R}/\mathbb{Z}\),即实数模 1 的商群。在这个代数结构上,加法自然是模 1 的加法,乘法则由整数与环面元素的标量乘定义。TFHE 定义了两类基本密文格式:TLWE(Torus Learning With Errors)和 TGLWE(Torus General Learning With Errors)。TLWE 样本形如 \((\mathbf{a}, b) \in \mathbb{T}^n \times \mathbb{T}\),其中 \(b = \langle \mathbf{a}, \mathbf{s} \rangle + m + e\),\(\mathbf{s}\) 为二进制密钥,\(m\) 为明文嵌入,\(e\) 为小噪声。TGLWE 则将标量推广为多项式环 \(\mathbb{T}_N[X] = \mathbb{T}[X]/(X^N+1)\) 上的元素,从而支持多项式级别的 SIMD 打包。
在 TFHE 中,还有一种重要的密文格式——TRGSW(Torus Ring GSW),它将 GSW 方案的矩阵密文搬到多项式环上。TRGSW 密文与 TGLWE 密文之间的外积(external product)运算是自举过程的关键积木:它实现了”受控选择”——根据 TRGSW 中加密的比特值,对 TGLWE 密文进行条件旋转。
2.2 门自举:噪声刷新的核心机制
TFHE 门自举(gate bootstrapping)的目标是:给定一个噪声较大的 TLWE 密文,输出一个噪声被刷新到固定小值的新 TLWE 密文,同时可以”顺便”计算一个布尔门(如 NAND、AND、OR)。其流程可以概括为三步。
第一步,模数切换(modulus switching):将 TLWE 密文的系数从连续环面离散化到 \(\mathbb{Z}_{2N}\)(通常 \(N = 1024\)),得到整数向量 \((\bar{a}_1, \dots, \bar{a}_n, \bar{b})\)。
第二步,盲旋转(blind rotation):构造一个”测试多项式”(test polynomial)\(v(X) \in \mathbb{T}_N[X]\),其系数编码了期望的输出映射。然后利用自举密钥(bootstrapping key,由密钥各比特的 TRGSW 加密构成),逐步对累加器(accumulator)中的 TGLWE 密文执行 \(X^{\bar{a}_i \cdot s_i}\) 的旋转。经过 \(n\) 步外积运算后,累加器存储的恰好是 \(v(X) \cdot X^{-\bar{b} + \sum \bar{a}_i s_i}\),即测试多项式被旋转了”解密相位”对应的步数。
第三步,样本提取(sample extraction):从 TGLWE 密文中提取常数项,得到一个低噪声的 TLWE 密文。如果测试多项式的系数设置得当,该 TLWE 密文正好加密了所需的布尔门输出。
门自举的时间复杂度主要由盲旋转中的 \(n\) 次外积运算决定,每次外积涉及多项式乘法(通过 NTT/FFT 加速),总开销约为 \(O(n \cdot N \log N)\)。在 2020 年的软件实现中,单次门自举约需 10 毫秒。
以下伪代码描述了完整的 TFHE 门自举流程,包含从 LWE 样本提取到最终结果输出的四个阶段:
GateBootstrap(TLWE 密文 ct = (a₁,...,aₙ,b), 自举密钥 BSK, 密钥切换密钥 KSK,
测试多项式 v(X)):
// BSK[i] = TRGSW_S(sᵢ),i = 1,...,n —— 原始密钥各比特的 TRGSW 加密
// KSK —— 从 TGLWE 密钥 S 到目标 TLWE 密钥 s' 的密钥切换密钥
// v(X) ∈ T_N[X] —— 测试多项式,其系数编码查找表
// ==== 阶段一:提取 LWE 样本并模数切换 ====
// 从输入密文中提取整数化的 LWE 样本
for i = 1 to n:
āᵢ ← round(2N · aᵢ) mod 2N // 将环面系数离散化到 Z_{2N}
b̄ ← round(2N · b) mod 2N
// ==== 阶段二:初始化累加器 ====
// ACC 是一个 TGLWE 密文,初始化为平凡加密(噪声为零)
ACC ← TrivialTGLWE( X^{-b̄} · v(X) )
// 将测试多项式预旋转 -b̄ 个位置
// 后续盲旋转将补偿密钥相关的偏移 Σāᵢsᵢ
// ==== 阶段三:盲旋转(核心——n 次 CMux 门) ====
for i = 1 to n:
ACC ← CMux( BSK[i], X^{āᵢ} · ACC, ACC )
//
// CMux(C, d₁, d₀) = C ⊡ (d₁ - d₀) + d₀
// ⊡ 为 TRGSW × TGLWE 外积运算
// 若 C = TRGSW(1) → 输出 ≈ d₁ = X^{āᵢ} · ACC (旋转)
// 若 C = TRGSW(0) → 输出 ≈ d₀ = ACC (不动)
//
// 每次 CMux 涉及 2(k+1)ℓ 次多项式乘法
// k = TGLWE 维度,ℓ = gadget 分解位数
// 循环结束后:
// ACC ≈ TGLWE_S( X^{ -b̄ + Σ āᵢsᵢ } · v(X) )
// = TGLWE_S( X^{ -round(phase) } · v(X) )
// phase = b - ⟨a,s⟩ ≈ m·Δ 为解密相位
// ==== 阶段四:样本提取与密钥切换 ====
tlwe_result ← SampleExtract(ACC, 0)
// 提取 TGLWE 密文的常数项 → 得到 TLWE 密文(密钥为 S 的展开形式)
// 该密文加密的值 = v(X) 在 X^{-round(phase)} 处的常数项
// = LUT[ round(m·Δ) ]
result ← KeySwitch(KSK, tlwe_result)
// 将密钥从展开形式的 S 切换回原始 TLWE 密钥 s'
// 便于后续链式运算
return result // 低噪声 TLWE 密文,加密 LUT[round(m·Δ)]
复杂度分析。 盲旋转阶段恰好执行 \(n\) 次 CMux 门(\(n\) 为 LWE 维度,典型值 \(n \geq 630\)),因此总复杂度为 \(O(n)\) 次 CMux 操作。每次 CMux 的计算代价主要是一次 TRGSW 与 TGLWE 的外积运算,涉及 \(2(k+1)\ell\) 次多项式乘法(其中 \(k\) 是 TGLWE 的维度,\(\ell\) 是分解位数),每次多项式乘法通过 NTT 在 \(O(N \log N)\) 时间内完成。因此单次门自举的总计算量为 \(O(n \cdot k \cdot \ell \cdot N \log N)\)。\(n\) 次 CMux 之间存在严格的数据依赖(第 \(i+1\) 步的 ACC 依赖第 \(i\) 步的输出),无法在步间并行——这正是门自举延迟的根本来源。
从门自举到可编程自举。 上述伪代码中测试多项式 \(v(X)\) 的系数可以自由设定——这意味着自举不仅能刷新噪声,还能同时查表计算任意函数。只需将目标函数 \(f\) 的值域编码为 \(v(X)\) 的系数:令 \(v_j = f(j)\),则自举输出恰好是 \(f(m)\) 的加密。这就是可编程自举(PBS)的核心机制,其计算代价与普通门自举完全相同——函数复杂度被”吸收”进测试多项式的系数中,不影响运行时间。
2.3 可编程自举:查找表计算
可编程自举(Programmable Bootstrapping, PBS)是 TFHE 最令人兴奋的特性之一。其核心洞察是:盲旋转中的测试多项式 \(v(X)\) 的系数可以自由设定——这意味着自举不仅能刷新噪声,还能同时计算任意函数。具体而言,如果明文域被离散化为 \(2N\) 个值,那么测试多项式的 \(N\) 个系数(利用反循环多项式的否定缠绕性质,实际可编码 \(2N\) 个值)就构成了一张查找表(Look-Up Table, LUT)。对输入密文执行一次 PBS,即可得到该查找表在输入值处的函数值,且输出噪声被刷新。
这一机制的威力在于:sigmoid、ReLU、比较、取整等非线性函数都可以通过 PBS 一步完成,而不需要像 BGV/BFV 那样用多项式近似来逼近。更进一步,Carpov、Izabachène 和 Jutla 在 2022 年提出了”功能性自举”(functional bootstrapping)的链式组合技术——通过将多个 PBS 串联或树形组合,可以在保持低噪声的同时计算任意精度的函数。
2.4 Python 示例:简化 TFHE 风格的 LWE 加密与自举概念演示
以下代码展示了 TFHE 风格 LWE 加密的基本结构和自举的概念性演示。为便于理解,我们在整数模数上操作,省略了完整的盲旋转,但保留了核心思路——通过查找表刷新噪声并计算函数。
import numpy as np
# ---- 参数设置 ----
n = 4 # LWE 维度(实际 TFHE 中 n >= 630)
q = 1024 # 密文模数
t = 4 # 明文模数(明文空间 {0, 1, 2, 3})
delta = q // t # 缩放因子,将明文嵌入到模 q 空间
np.random.seed(42)
# ---- 密钥生成 ----
s = np.random.randint(0, 2, size=n) # 二进制密钥
# ---- LWE 加密 ----
def lwe_encrypt(m, s, q, delta):
"""加密明文 m ∈ Z_t 为 LWE 样本 (a, b) ∈ Z_q^n × Z_q"""
a = np.random.randint(0, q, size=len(s))
e = np.random.randint(-2, 3) # 小噪声
b = (np.dot(a, s) + m * delta + e) % q
return (a, b)
# ---- LWE 解密 ----
def lwe_decrypt(ct, s, q, delta):
"""解密 LWE 密文,还原明文 m ∈ Z_t"""
a, b = ct
phase = (b - np.dot(a, s)) % q # 解密相位 = m·delta + e
# 四舍五入到最近的 delta 整数倍
m = round(phase / delta) % (q // delta)
return int(m)
# ---- 简化的"自举":模拟查找表噪声刷新 ----
def simulated_pbs(ct, s, q, delta, lut_func):
"""
模拟可编程自举 (PBS):
1. 先解密得到相位(真正的 TFHE 中此步在密文域用盲旋转完成)
2. 通过查找表 lut_func 计算函数值
3. 重新加密,噪声被刷新
"""
# 概念性解密相位(在真正 TFHE 中由盲旋转同态完成)
a, b = ct
phase = (b - np.dot(a, s)) % q
input_val = round(phase / delta) % (q // delta)
# 查找表计算
output_val = lut_func(input_val)
# 重新加密(噪声被刷新为新鲜小噪声)
fresh_ct = lwe_encrypt(output_val, s, q, delta)
return fresh_ct
# ---- 演示 ----
print("=" * 50)
print("TFHE 风格 LWE 加密与可编程自举演示")
print("=" * 50)
# 基本加解密
m_original = 3
ct = lwe_encrypt(m_original, s, q, delta)
m_dec = lwe_decrypt(ct, s, q, delta)
print(f"\n[加解密] 明文 = {m_original}, 解密 = {m_dec}, "
f"正确: {m_original == m_dec}")
# 同态加法(直接密文相加)
m1, m2 = 1, 2
ct1 = lwe_encrypt(m1, s, q, delta)
ct2 = lwe_encrypt(m2, s, q, delta)
ct_add = (
(ct1[0] + ct2[0]) % q,
(ct1[1] + ct2[1]) % q
)
m_add = lwe_decrypt(ct_add, s, q, delta)
print(f"[同态加法] {m1} + {m2} = {m_add}, "
f"正确: {m_add == (m1 + m2) % (q // delta)}")
# 可编程自举——查找表计算平方模 t
square_mod_t = lambda x: (x * x) % (q // delta)
ct_input = lwe_encrypt(2, s, q, delta)
ct_pbs = simulated_pbs(ct_input, s, q, delta, square_mod_t)
m_pbs = lwe_decrypt(ct_pbs, s, q, delta)
print(f"[可编程自举] f(2) = 2² mod {q // delta} = {m_pbs}, "
f"正确: {m_pbs == square_mod_t(2)}")
# 多次运算后噪声积累 vs 自举刷新演示
print(f"\n--- 噪声积累演示 ---")
ct_acc = lwe_encrypt(1, s, q, delta)
for i in range(8):
ct_acc = (
(ct_acc[0] + ct1[0]) % q,
(ct_acc[1] + ct1[1]) % q
)
a_acc, b_acc = ct_acc
raw_phase = (b_acc - np.dot(a_acc, s)) % q
noise_est = min(raw_phase % delta, delta - raw_phase % delta)
print(f" 8 次加法后噪声估计: {noise_est} (阈值: {delta // 2} = {delta // 2})")
# PBS 刷新
identity = lambda x: x % (q // delta)
ct_refreshed = simulated_pbs(ct_acc, s, q, delta, identity)
a_ref, b_ref = ct_refreshed
raw_phase_ref = (b_ref - np.dot(a_ref, s)) % q
noise_ref = min(raw_phase_ref % delta, delta - raw_phase_ref % delta)
print(f" 自举刷新后噪声估计: {noise_ref}")
print(f" 解密结果: {lwe_decrypt(ct_refreshed, s, q, delta)}")上述代码中,simulated_pbs
函数以”先解密再重新加密”的方式模拟了可编程自举的效果。在真正的
TFHE
实现中,这一过程完全在密文域内通过盲旋转完成——服务器永远无法接触明文。代码的核心教学意义在于展示了三个关键概念:LWE
加密的 \((\mathbf{a}, b)\)
结构、噪声在同态运算中的积累、以及自举通过查找表同时完成噪声刷新与函数计算。
三、多密钥与多方 FHE
3.1 多密钥 FHE(Multi-Key FHE, MKFHE)
传统 FHE 要求所有数据在同一把公钥下加密,这在多方场景中显得不切实际——参与方不愿将私数据用他人的密钥加密。多密钥 FHE(Multi-Key FHE, MKFHE)解决了这一问题:不同参与方各自用自己的密钥加密数据,服务器可以对这些”异构密文”直接执行同态计算,最终结果需要所有相关密钥持有者协作解密。
López-Alt、Tromer 和 Vaikuntanathan 在 2012 年提出了首个 MKFHE 方案,基于 NTRU 假设。此后,Chen、Chillotti 和 Song 在 2019 年给出了基于 TFHE 的 MKFHE 构造,支持高效的多密钥自举。其关键技巧是将单密钥盲旋转推广为多密钥盲旋转——在每一步中,不是用单个密钥比特的 TRGSW 加密来旋转累加器,而是用所有参与方对应比特的 TRGSW 加密依次旋转。自举开销与参与方数量 \(k\) 线性相关,整体复杂度约为 \(O(k \cdot n \cdot N \log N)\)。
3.2 门限 FHE(Threshold FHE)
门限 FHE 是 MKFHE 的一个重要变体:密钥被秘密共享为 \(k\) 份,解密时需要至少 \(t\) 个参与方协作。与 MKFHE 不同,门限 FHE 中所有数据在同一把公钥下加密(该公钥由分布式密钥生成协议产生),因此同态计算的效率与单密钥方案相同,额外开销仅出现在分布式解密阶段。Boneh、Gennaro 和 Goldfeder 在 2018 年提出了高效的门限 CKKS 方案,已被应用于隐私保护联邦学习中——模型聚合在密文上完成,各方协作解密聚合结果,全程无人能看到其他方的模型更新。
3.3 应用:无交互多方安全计算
MKFHE 的一个极具吸引力的应用是将多方安全计算(MPC)的交互轮数降至最低。在经典的 MPC 协议中,参与方需要多轮交互来评估电路;而使用 MKFHE,各方只需一轮广播(发送各自密文),服务器在密文上完成全部计算,最后一轮交互用于分布式解密。这种”两轮 MPC”模式在网络延迟高或参与方不在线的场景下极具价值。
3.4 多密钥 FHE 的一致性保障与威胁模型
多密钥 FHE 在安全假设和威胁模型上与单密钥 FHE 存在本质差异,部署时必须充分理解以下问题:
威胁模型的关键区别。 单密钥 FHE 的标准威胁模型假设服务器”诚实但好奇”(honest-but-curious),即服务器正确执行计算但试图推断信息。在 MKFHE 中,威胁模型更加复杂:(1)服务器可能恶意,返回错误计算结果;(2)部分参与方可能串谋,试图推断其他参与方的私有数据;(3)参与方可能在分布式解密阶段提交错误的解密份额(“解密欺骗”)。
密钥一致性问题。 在 MKFHE 中,同态运算需要将不同密钥下的密文”扩展”(expand)到联合密钥空间。这一扩展过程引入了密钥一致性约束——所有参与方必须就”谁参与了哪次计算”达成共识。如果参与方 A 提交了在密钥 \(pk_A\) 下加密的数据,但后来声称自己使用的是不同的密钥 \(pk_A'\),分布式解密将失败或产生错误结果。解决方案是要求参与方在提交密文时同时提交公钥的承诺(commitment),并在解密阶段验证一致性。
分布式解密的安全性。 MKFHE 的解密需要所有相关密钥持有者协作——这引入了可用性风险:任何一个参与方的拒绝或离线都会导致结果无法解密。门限变体(如 \((t, k)\)-门限 MKFHE)可以缓解这一问题,允许 \(k\) 个参与方中任意 \(t\) 个完成解密。然而,门限 MKFHE 的构造目前仍处于理论阶段,效率远低于标准 MKFHE。
MKFHE 构造概要:扩展密文。 MKFHE 的核心构造思路是将单密钥密文”扩展”为联合密文。在单密钥 LWE 中,密文 \((a, b)\) 满足 \(b = \langle a, s \rangle + m + e\);在 \(k\) 方 MKFHE 中,密文被扩展为 \((a_1, a_2, \dots, a_k, b)\),满足 \(b = \sum_{j=1}^{k} \langle a_j, s_j \rangle + m + e\),其中 \(s_j\) 是第 \(j\) 方的私钥。当第 \(j\) 方提交一个单密钥密文时,系统将其嵌入联合密文空间——只在第 \(j\) 个分量中放置原始 \(a\) 向量,其余分量置零。同态运算在扩展密文上进行,密文维度随参与方数量线性增长。这种”无可信分发者”的设计确保任何参与方都无需向他人暴露私钥。
分布式解密协议。 MKFHE 的解密需要所有密钥持有者协作完成。协议流程如下:(1)服务器将最终密文 \((a_1, \dots, a_k, b)\) 广播给所有参与方;(2)第 \(j\) 方计算部分解密份额 \(d_j = \langle a_j, s_j \rangle + e_j^{\text{flood}}\),其中 \(e_j^{\text{flood}}\) 是一个精心选取的大噪声(噪声淹没,noise flooding);(3)各方提交 \(d_j\) 后,聚合方计算 \(m \approx b - \sum d_j\) 并进行舍入。噪声淹没是保证模拟安全性(simulation security)的关键技术——如果不添加 \(e_j^{\text{flood}}\),部分解密份额 \(d_j\) 会泄露密钥 \(s_j\) 的信息;通过添加远大于密文噪声但远小于明文间隔的淹没噪声,可以在信息论意义上掩盖密钥信息,使得协议可被安全模拟。
串谋阈值与安全边界。 MKFHE 的安全性要求抵抗至多 \(k-1\) 方的串谋——即使 \(k-1\) 个参与方联合攻击,也无法推断诚实方的私有输入。这一安全性直接继承自底层 LWE 假设的困难性:串谋者掌握的信息可以归约为一个 LWE 实例。然而需要注意的是,噪声淹没参数 \(e_j^{\text{flood}}\) 的选取必须与安全参数和串谋阈值匹配——淹没噪声过小会导致模拟不成立,过大则会超出解密容错范围。统计安全参数通常取 \(\lambda_{\text{stat}} \geq 40\),即淹没噪声的方差需要比密文噪声大 \(2^{40}\) 倍以上。
噪声增长与参与方数量的实际限制。 MKFHE 的同态运算噪声增长与参与方数量 \(k\) 直接相关。在 TFHE-based MKFHE 中,盲旋转的噪声与 \(k\) 线性相关,这意味着参与方数量的上限受到自举噪声预算的约束。当前实现通常支持 \(k \leq 8\) 到 \(k \leq 16\) 个参与方;超过这一范围需要增大 LWE 参数,导致显著的性能退化。
MKFHE 与门限 FHE 的对比。 两者针对不同的信任假设而设计。MKFHE 适用于”无可信第三方、各方独立持密钥”的场景——参与方之间事先无需任何交互即可各自加密数据,系统在运行时动态扩展密文空间。门限 FHE 则预设一个分布式密钥生成阶段(DKG),所有参与方协作生成一把联合公钥和各自的密钥份额——同态计算阶段的效率与单密钥方案完全一致,代价是需要一次性的初始化交互。在实际部署中,如果参与方集合固定且可预先协调(如联邦学习中的固定机构联盟),门限 FHE 通常是更优选择;如果参与方动态加入、事先互不知晓(如链上隐私计算),MKFHE 是必要的。
| 维度 | 单密钥 FHE | 多密钥 FHE(MKFHE) | 门限 FHE |
|---|---|---|---|
| 加密密钥 | 所有数据用同一公钥 | 每方用自己的公钥 | 分布式生成的联合公钥 |
| 服务器信任 | 诚实但好奇 | 可恶意(需搭配 ZKP) | 诚实但好奇 |
| 参与方串谋 | 不适用(单方) | 需抗 \((k-1)\) 方串谋 | 需抗 \((t-1)\) 方串谋 |
| 同态运算开销 | 基准 | \(O(k)\) 倍于基准 | 与单密钥相同 |
| 解密交互 | 无(单方解密) | \(k\) 方各出解密份额 | \(t\) 方各出解密份额 |
| 可用性风险 | 无 | 任一方离线即阻塞 | 可容忍 \(k - t\) 方离线 |
| 实用参与方数上限 | 1 | ~8-16(当前实现) | ~8-32 |
四、FHE 编译器技术
4.1 从高级语言到 FHE 电路
FHE 编程的核心痛点在于:开发者需要将高级算法手动转化为 FHE 方案支持的原语(加法、乘法、旋转),并精心管理噪声预算和参数选择。FHE 编译器的目标正是自动化这一过程。
Zama 公司的 Concrete 编译器是当前最成熟的 TFHE 编译器。开发者用 Python 编写普通函数,Concrete 编译器将其自动转化为 TFHE 电路:首先通过追踪(tracing)获取计算图,然后进行数据类型推断(确定每个中间值所需的位宽),接着选择最优的 TFHE 参数(LWE 维度、多项式阶数、分解基数等),最后生成可执行的 FHE 程序。关键优化包括:将多个连续的 PBS 融合为一次 PBS(通过组合查找表),以及利用 SIMD 打包在单次 PBS 中并行处理多个值。
4.2 HEIR 与 MLIR FHE 方言
谷歌主导的 HEIR(Homomorphic Encryption Intermediate Representation)项目采用了不同的技术路线——基于 MLIR(Multi-Level Intermediate Representation)编译器基础设施构建 FHE 方言。HEIR 定义了多层抽象:最高层是”秘密”方言(secret dialect),标记哪些数据是加密的;中间层是”FHE”方言,表示 BGV/CKKS/TFHE 等方案的运算;最底层映射到具体的密码学库调用(如 OpenFHE、SEAL)。
这种分层设计的优势在于:优化可以在不同抽象层独立进行。例如,在秘密方言层可以做通用的数据流优化(死代码消除、公共子表达式合并);在 FHE 方言层可以做方案特定的优化(旋转合并、自举位置插入);在库映射层可以做目标特定的代码生成。HEIR 已支持将 TensorFlow/JAX 模型自动编译为 FHE 推理程序。
4.3 自动参数选择与噪声预算优化
FHE 参数选择是一个多目标优化问题:需要同时满足安全性(通常要求 128 位安全)、正确性(噪声不超过解密阈值)和性能(密文大小和计算速度)。自动参数选择器(如 Concrete 中的优化器和 Lattice Estimator 工具)会遍历参数空间,根据电路的乘法深度、自举次数和安全约束,求解最优参数组合。
噪声预算优化的另一个重要技术是”惰性自举”(lazy bootstrapping)——不在每次门运算后立即自举,而是追踪当前噪声水平,仅在噪声即将溢出时才插入自举。这需要编译器对整个计算图进行全局分析,找到自举次数最少的调度方案。研究表明,优化的自举调度可以将总自举次数减少 30% 至 50%。
五、硬件加速:FPGA 与 ASIC
5.1 性能瓶颈分析
FHE 运算的性能瓶颈主要来自三个方面。首先是计算密集性:NTT(Number Theoretic Transform)是多项式乘法的核心算法,在 TFHE 自举中占据 60% 以上的计算时间。其次是内存带宽:FHE 密文体积庞大(一个 CKKS 密文在 \(N = 2^{16}\) 时约 8 MB),频繁的内存读写成为瓶颈。第三是密钥材料访问:自举密钥(bootstrapping key)在 TFHE 中可达数百 MB,每次自举都需要流式读取。
5.2 Intel HEXL 与指令集优化
英特尔的 HEXL(Homomorphic Encryption Acceleration Library)并非专用硬件,而是利用 AVX-512 等 SIMD 指令集加速 NTT、Barrett 约化和逐元素模乘等核心运算。HEXL 为 SEAL、HElib、PALISADE 等主流 FHE 库提供后端加速,在 Xeon 处理器上可获得 3 至 8 倍的加速比。其价值在于”零成本升级”——现有 FHE 应用无需修改代码即可受益。
5.3 BASALISC 架构
BASALISC 是由 Cousins 和 Rohloff 在 2023 年提出的 FHE 专用 ASIC 架构设计。其核心思路是”计算靠近数据”——在大容量片上 SRAM 阵列中直接嵌入 NTT 蝶形运算单元和模乘器,避免密文数据在计算单元和主存之间频繁搬运。BASALISC 架构针对 BFV/CKKS 方案优化,设计目标是在 7nm 工艺下实现对 CPU 四到五个数量级的加速。其关键设计特征包括:分层 NTT 数据流(将大规模 NTT 分解为多级小 NTT,每级在片上完成)、宽位模乘阵列(支持 64 位和 128 位模数的并行约化)、以及可配置的密文布局(适应不同参数集的密文格式)。
5.4 CryptoLight 与光计算
CryptoLight 探索了一条更为激进的路线——利用光子集成电路(photonic integrated circuit)加速 NTT 运算。光计算的天然优势在于矩阵-向量乘法可以在光域中以光速完成,且能耗极低。CryptoLight 使用微环谐振器(micro-ring resonator)阵列实现模乘,用马赫-曾德尔干涉仪(Mach-Zehnder interferometer)网络实现蝶形运算。初步仿真表明,在 NTT 阶数 \(N = 2^{16}\) 时,光子 NTT 加速器的延迟可低至电子方案的百分之一,能耗降低两个数量级。当然,光计算方案尚处于早期研究阶段,精度控制和工艺成熟度仍是主要挑战。
5.5 FPGA 加速的实践案例
相比 ASIC 的高前期投入,FPGA 提供了灵活且可快速部署的加速方案。Xilinx/AMD Alveo 系列加速卡已被多个团队用于 FHE 加速。典型的 FPGA 加速架构包括:专用 NTT 引擎(利用 BRAM 存储蝶形中间结果,DSP 单元执行模乘)、密钥缓存模块(将自举密钥的热点部分预加载到片上存储)、以及流水线化的外积运算单元。在 TFHE 自举场景下,高端 FPGA 方案可实现 10 至 50 倍的加速(相对于优化的 CPU 实现)。
六、GPU 加速
6.1 cuFHE 与早期探索
cuFHE 是最早将 TFHE 门自举移植到 NVIDIA GPU 的开源库之一。其核心思路是利用 GPU 的大规模并行性加速 NTT:将 \(N\) 点 NTT 映射为 \(\log N\) 轮蝶形运算,每轮的 \(N/2\) 个蝶形操作可以完全并行。cuFHE 在 RTX 2080 上实现了单次门自举约 1 毫秒的延迟,相比 CPU 实现(约 10 毫秒)提速约 10 倍。
6.2 phantom-FHE 与现代 GPU 加速
phantom-FHE 是新一代的 GPU FHE 库,支持 CKKS、BFV 和 TFHE 三种主流方案。相比 cuFHE,phantom-FHE 做了多项关键优化:内核融合(kernel fusion)——将 NTT、逐元素乘法和 INTT 合并为单个 CUDA 核函数,减少全局内存读写;流水线异步执行——利用 CUDA 流(stream)重叠计算与数据传输;批量摊销——同时处理多个独立的密文运算,最大化 GPU 利用率。在 A100 GPU 上,phantom-FHE 的 CKKS 乘法吞吐量可达每秒数万次(\(N = 2^{15}\)),自举延迟约 0.1 秒。
6.3 NTT 在 GPU 上的优化
NTT 是 GPU 加速 FHE 的关键基础运算。在 GPU 上实现高效 NTT 面临两个挑战:一是”蝶形阶段”的并行粒度随阶段变化——初始阶段并行度高但数据局部性差,后期阶段并行度低但局部性好;二是模运算(模乘、模约化)在 GPU 上没有原生硬件支持。
针对第一个挑战,主流方案采用”分层 NTT”策略:将一个大 NTT 分解为多轮”局部 NTT + 旋转因子乘法 + 转置”的迭代,每轮局部 NTT 在共享内存(shared memory)中完成,保证数据局部性;转置操作则利用 GPU 的全局内存合并访问(coalesced access)机制优化。针对第二个挑战,Barrett 约化和 Montgomery 约化被广泛使用,后者特别适合 GPU 的整数乘法单元。
6.4 批量摊销加密
GPU 加速 FHE 的另一大优势是批量摊销(amortized batch)。在许多应用场景中(如数据库查询、机器学习推理),需要对大量独立数据执行相同的 FHE 运算。将这些运算打包为一个 GPU 批次,可以充分利用 GPU 的数千个核心。实验表明,在批量足够大时(如 \(> 1024\) 个独立运算),GPU 的摊销延迟可接近每个运算仅需微秒级别,与 CPU 上单个运算的毫秒级延迟形成数量级差距。
七、FHE + MPC 混合架构
7.1 为何需要混合
FHE 和 MPC 各有其适用领域和局限。FHE 擅长处理线性运算和多项式计算(加法、乘法链),但在非线性运算(比较、截断、符号函数)上效率低下——这些操作通常需要深层电路或大量自举。MPC 擅长处理比较和位运算(利用混淆电路或秘密共享),但交互开销与电路大小和参与方数量成正比。混合架构的核心思想是”各取所长”:用 FHE 处理大规模线性运算(如矩阵乘法),用 MPC 处理少量非线性运算(如 ReLU 比较)。
7.2 实用框架与协议设计
典型的混合框架流程如下:参与方在本地对数据进行 FHE 加密,将密文发送至计算服务器;服务器对密文执行线性运算(全在 FHE 下完成,无需交互);当遇到非线性运算时,服务器与参与方之间切换到 MPC 协议——服务器将中间密文”分享化”(secret share),参与方与服务器联合执行混淆电路或加法秘密共享协议完成非线性计算,然后将结果重新加密为 FHE 密文,继续后续的线性运算。
这一模式已在隐私保护机器学习推理中得到验证。以 ResNet-20 在 CIFAR-10 上的推理为例:卷积层(线性运算占 90% 以上的计算量)全部用 FHE 在服务器上完成,ReLU 激活(非线性运算但数量相对较少)通过一轮 MPC 交互完成。实验表明,混合方案的端到端延迟比纯 FHE 方案减少 5 到 10 倍,比纯 MPC 方案减少 2 到 5 倍的通信量。
7.3 协议转换的开销
混合架构的关键技术挑战在于”协议转换”(protocol switching):FHE 密文和 MPC 秘密共享之间的转换需要一定的交互和计算开销。从 FHE 密文到加法秘密共享,需要参与方协作执行一次分布式解密(或部分解密);从秘密共享到 FHE 密文,需要参与方将各自的份额加密后由服务器同态求和。这些转换的开销决定了混合架构中”切换点”的选择——过于频繁的切换会使转换开销抵消混合架构的收益。因此,编译器级别的优化(最小化切换次数)是混合架构实用化的关键。
八、FHE + ZKP:可验证同态计算
8.1 可验证 FHE 的动机
在 FHE 的标准模型中,计算服务器被假设为”诚实但好奇”(honest-but-curious)——它正确执行计算,但试图从密文中推断信息。然而,在现实场景中,服务器可能是恶意的——它可能故意返回错误的计算结果。可验证 FHE(Verifiable FHE)的目标是:让服务器在返回密文结果的同时附带一个零知识证明,证明该结果确实是对输入密文正确执行了指定计算所得。
8.2 Rinocchio 及相关方案
Rinocchio 是 Ganesh、Nitulescu 和 Pashov 在 2021 年提出的可验证 FHE 方案。其核心思路是将 FHE 计算表示为关于密文系数的算术电路,然后利用类 Pinocchio 的 SNARK 系统对该电路生成证明。具体而言,Rinocchio 将 BFV 方案的同态乘法展开为关于多项式系数的二次约束系统(R1CS),然后利用格基承诺方案(lattice-based commitment)生成后量子安全的 SNARK 证明。
然而,直接对 FHE 运算生成 ZKP 面临巨大的开销:一次同态乘法涉及的约束数量可达数百万。为此,研究者提出了多种优化策略。一是”分摊验证”——对批量 FHE 运算生成一个聚合证明,而非逐个证明。二是”承诺-计算-证明”框架——服务器先对输入密文和中间结果做出承诺,再证明承诺之间的关系满足正确计算的约束。三是将 FHE 运算的正确性验证与区块链结合——利用链上验证合约检查 SNARK 证明,实现去中心化的可验证加密计算。
8.3 实际应用:可审计的加密数据分析
可验证 FHE 在合规与审计场景中具有特殊价值。例如,金融机构将加密的交易数据外包给云服务器进行反洗钱分析,服务器返回分析结果的同时附带正确性证明,监管机构无需看到原始交易数据即可验证分析过程的合规性。又如,在加密投票系统中,计票服务器在密文上执行计票运算,并生成证明,任何人都可以验证计票结果确实是对所有加密选票正确求和所得。
九、FHE 的未来路线图
9.1 标准化进程
HomomorphicEncryption.org 是由学术界和工业界共同成立的 FHE 标准化组织,其目标是制定 FHE 方案的安全参数推荐、API 规范和互操作性标准。截至目前,该组织已发布三份白皮书:安全参数标准(给出不同安全级别下 LWE/RLWE 维度和模数的推荐值)、API 标准草案(定义加密、解密、同态运算等核心接口)和应用标准草案(针对隐私保护机器学习、加密数据库查询等典型场景的最佳实践)。标准化的推进将显著降低 FHE 的使用门槛,并促进不同实现之间的互操作。
9.2 性能里程碑
从性能角度看,FHE 社区正在追求几个关键里程碑。第一是”一毫秒自举”——将 TFHE 门自举的延迟从当前的约 10 毫秒降至 1 毫秒以下,这需要硬件加速与算法优化的协同。第二是”实时 CKKS 推理”——在加密数据上运行 BERT 级别的大语言模型推理,延迟低于一秒。第三是”密文膨胀率低于十倍”——通过密文压缩和转码技术,使加密数据的传输和存储开销降至可接受范围。每一个里程碑的达成都将解锁新的应用场景。
9.2.1 当前性能基准数据
为了给上述里程碑提供定量参照,以下汇总截至 2025 年公开报道的代表性基准测试结果:
| 方案/操作 | 平台 | 延迟 | 吞吐量 | 来源 |
|---|---|---|---|---|
| TFHE 门自举 | CPU(AMD EPYC, Zama TFHE-rs) | ~8 ms | ~125 gates/s | Zama TFHE-rs v0.7 基准,2024 |
| TFHE 门自举 | GPU(NVIDIA A100, phantom-FHE) | ~0.5-1 ms | ~2000 gates/s | phantom-FHE 论文,2024 |
| CKKS 乘法(\(N = 2^{16}\)) | CPU(Intel Xeon, OpenFHE) | ~5 ms | ~200 ops/s | OpenFHE v1.2 基准,2024 |
| CKKS 乘法(\(N = 2^{16}\)) | GPU(A100, 100x.ai) | ~0.1 ms | ~10000 ops/s | 100x.ai 技术报告,2024 |
| CKKS 自举(\(N = 2^{16}\)) | CPU(OpenFHE) | ~40-60 s | — | OpenFHE/HEAAN 基准 |
| CKKS 自举(\(N = 2^{16}\)) | GPU(A100) | ~2-5 s | — | 学术报告,2024 |
| Concrete ML 逻辑回归推理 | CPU(Zama Concrete ML) | ~100 ms | — | Zama Concrete ML v1.5 基准,2024 |
| ResNet-20 CIFAR-10 推理 | 混合 FHE+MPC | ~3-10 s(端到端) | — | CrypTFlow2/BOLT,2023 |
| 逻辑回归训练(10 万样本) | CKKS GPU | ~15 min | — | HEaaN-MLlib,2024 |
与 2020 年性能基线的对比。 以下数据揭示了过去五年 FHE 工程化的加速轨迹:
| 操作 | 2020 年典型延迟 | 2024 年典型延迟 | 改善倍数 | 主要驱动因素 |
|---|---|---|---|---|
| TFHE 门自举(CPU) | ~50-100 ms(TFHE-lib, C++) | ~8 ms(TFHE-rs, Rust) | 6-12x | Rust 重写、AVX-512、参数优化 |
| CKKS 密文乘法(CPU) | ~50 ms(HElib, \(N=2^{15}\)) | ~5 ms(OpenFHE, \(N=2^{16}\)) | ~10x | HEXL 加速、RNS 优化、NTT 改进 |
| CKKS 密文乘法(GPU) | ~5 ms(cuHE 原型) | ~0.1 ms(100x.ai) | ~50x | 内核融合、批量摊销、A100 架构 |
| 逻辑回归推理(FHE) | ~5-10 s(nGraph-HE) | ~100 ms(Concrete ML) | 50-100x | TFHE PBS 编译优化、自动参数选择 |
关键观察:(1)GPU 加速已将 TFHE 门自举推进到亚毫秒区间,“一毫秒自举”目标在 GPU 上已基本实现,CPU 上仍需约一个数量级的改善;(2)CKKS 自举仍然是最大瓶颈——即使在 GPU 上也需要数秒,这严重限制了深层计算的实用性;(3)端到端的机器学习推理延迟已从 2020 年的”分钟级”降至”秒级”,主要得益于混合架构和 GPU 加速的双重进步;(4)总体而言,2020 至 2024 年间 FHE 实现了 10 至 100 倍的性能改善,这一加速轨迹与深度学习框架在 2012-2017 年间的优化进程相当。
实用化时间线预估。 基于当前的改善轨迹和硬件路线图,可以给出以下粗略预测:2025-2026 年,CPU 上 TFHE 门自举进入 1-2 ms 区间,简单的加密分类和查询场景进入生产部署;2027-2028 年,FHE ASIC 首批商用芯片面世(DARPA DPRIVE 计划的成果转化),CKKS 自举降至亚秒级,中等规模神经网络(如 MobileNet)的加密推理延迟进入秒级;2029-2030 年,专用硬件普及后,大语言模型的加密推理进入分钟级可用范围。这些预测假设硬件和算法同步进步——任何一方的突破都可能显著提前时间线。
9.3 杀手级应用
展望未来,FHE 最有可能率先在以下场景中实现突破。隐私保护云计算——用户将加密数据上传至云端,云服务器在密文上直接执行查询、分析和机器学习推理,全程不接触明文,从根本上解决”数据可用不可见”的问题。加密数据库——支持在加密列上执行 SQL 查询(等值比较、范围查询、聚合运算),CipherBase、SealPIR 等项目已展示了初步可行性。链上隐私计算——在区块链智能合约中嵌入 FHE 运算,使得合约可以处理加密的状态数据,用户隐私不再对矿工和验证节点透明。Zama 的 fhEVM 项目正在将这一愿景付诸实践,允许 Solidity 开发者在加密整数上编写智能合约逻辑。
此外,FHE 与差分隐私(Differential Privacy, DP)的结合也值得关注——FHE 保护单个数据点的内容,DP 保护统计查询结果中的个体信息泄露,两者互补形成更强的隐私保障。在基因组分析、医疗数据联合研究等高敏感领域,FHE + DP 的组合方案正在被积极探索。
9.4 总结与展望
全同态加密经过十余年的发展,已从一个纯理论的密码学构造演变为拥有完整生态系统的实用化技术栈。TFHE 的可编程自举提供了计算任意函数的灵活性,多密钥 FHE 和门限 FHE 打开了多方协作计算的大门,Concrete 和 HEIR 等编译器大幅降低了开发门槛,FPGA/ASIC/GPU 硬件加速正在弥合性能差距,与 MPC 和 ZKP 的混合架构则将 FHE 融入更广泛的隐私计算版图。
当然,挑战依然存在。完全消除 FHE 的性能差距可能需要专用硬件的大规模部署,而这又依赖于足够大的市场需求来摊薄成本。编译器的自动化程度仍有提升空间——理想状态是开发者完全无需了解密码学细节即可编写 FHE 程序。标准化工作还需要更多行业参与者的共识。但总体趋势是明确的:FHE 正在从密码学家的论文走向工程师的工具箱,“数据可用不可见”的愿景正在一步步变为现实。
十、FHE 硬件加速平台成本与收益对照
全同态加密的计算开销是其走向大规模部署的核心瓶颈。不同硬件加速平台在开发成本、灵活性和加速效果之间存在显著的权衡关系。下表对主要加速平台进行系统对比。
| 维度 | CPU(基准) | GPU | FPGA | ASIC |
|---|---|---|---|---|
| 吞吐量提升 | 1x(基准线) | 10-50x | 50-200x | 100-1000x |
| 开发成本 | 低——直接使用现有 FHE 库(TFHE-rs、OpenFHE、SEAL) | 中——需要 CUDA/OpenCL 内核优化、NTT 和多项式运算的并行化 | 高——需要 RTL 设计、硬件描述语言开发、数月至一年的设计周期 | 极高——数百万至数千万美元的流片成本、1-2 年的设计到生产周期 |
| 灵活性 | 最高——算法参数和方案可随时更换 | 高——通过重新编写内核可适配不同 FHE 方案 | 中——可重新编程,但设计迭代周期以周计 | 最低——功能在流片时固化,无法修改 |
| 功耗效率 | 低——通用架构导致大量无效功耗 | 中——并行计算单元利用率高,但显存带宽可能成为瓶颈 | 高——定制数据通路避免冗余计算 | 最高——每瓦特性能最优 |
| 技术成熟度 | 成熟——所有主流 FHE 库均以 CPU 为首要目标平台 | 快速成长——NVIDIA 已发布 cuFHE 等库;多个学术项目展示了显著加速 | 活跃研究——Intel HEXL、多个 DARPA DPRIVE 项目正在推进 | 早期——DARPA DPRIVE 计划资助了多家团队(Duality、SRI、Intel 等)开发 FHE ASIC |
| 代表性项目 | TFHE-rs(Zama)、OpenFHE(DARPA)、Microsoft SEAL | cuFHE(NTT Research)、REDcuFHE、100x.ai GPU 加速 | Intel HEXL 加速库、FPT(FPGA-based FHE accelerator)、Xilinx Alveo 原型 | DARPA DPRIVE 计划下的 ASIC 原型、CryptoLight(光计算加速 FHE) |
笔者认为,FHE 硬件加速的演进轨迹与比特币挖矿的硬件迭代惊人地相似——CPU → GPU → FPGA → ASIC 的递进路径几乎如出一辙。比特币挖矿在 2009 年始于 CPU,2010 年转向 GPU,2011 年出现 FPGA 矿机,2013 年 ASIC 矿机彻底主导市场。FHE 加速正在重走这条路:2020 年前主要依赖 CPU,2021-2023 年 GPU 加速方案密集涌现,2023-2025 年 FPGA 原型进入测试,ASIC 设计则在 DARPA 资助下紧锣密鼓地推进。这一规律的底层逻辑是相同的——当一种计算模式具有高度规则的结构(大量多项式乘法和 NTT 变换),专用硬件的效率优势就会随着市场规模的扩大而逐步释放。但与比特币挖矿不同的是,FHE 的计算模式远更复杂多样(不同 FHE 方案的计算图差异显著),这意味着 FPGA 的可重编程优势在 FHE 领域可能比在挖矿领域持续更久。从工程实践来看,当前阶段最务实的选择是:用 GPU 加速获取即时收益(10-50 倍加速,开发周期数月),同时关注 FPGA 和 ASIC 的技术成熟度——当 FHE 标准化和应用场景趋于稳定时,专用硬件的投资才具有可预测的回报。
密码学百科系列 · 第 62 篇
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【密码学百科】同态加密:从 Paillier 到全同态加密(FHE)
同态加密允许在密文上直接计算——本文从部分同态(PHE)的 Paillier 方案出发,讲解 Gentry 的突破性 FHE 构造、BGV/BFV/CKKS 等实用方案,以及 FHE 在隐私机器学习和数据库查询中的前沿应用
全同态加密(FHE)技术详解
在数据为王的时代,数据隐私和安全变得至关重要。我们希望在利用数据带来价值的同时,保护其不被泄露。传统的数据加密技术(如 AES、RSA)可以有效地保护静态存储和传输中的数据,但一旦需要对数据进行计算或处理,就必须先解密。解密后的数据以明文形式暴露在内存中,极易受到攻击,这在云计算等第三方计算环境中构成了巨大的安全风险。
国密算法与国密 TLS 系列索引
从 SM3/SM4/SM2 的设计对比到国密 TLS 握手、生态落地、PQC 迁移——国密技术的完整知识图谱。
【密码学百科】密码学简史:从凯撒密码到量子时代
从古典密码的替换与置换,到现代密码学的数学革命,再到后量子时代的全新挑战——一篇文章带你走完密码学三千年的演进之路