2.5 备选路线：同态加密与零知识证明

2.5 备选路线：同态加密与零知识证明

本节摘要：同态加密（HE）把"在密文上算"变成单方可行，零知识证明（ZKP）把"证明我知道而不泄露我知道"变成可能。两者都不是 MPC，但都是 MPC 协议的常驻配角。本节给出它们的能力边界、典型用法与判断何时该请它们出场的标准。

核心概念

同态加密回答的问题是：能不能不解密就运算？加密方案若满足"密文的运算结果解密后等于明文运算结果"，就叫同态。按能力分三档：加法同态（Paillier 是代表）只支持密文相加与数乘；层次型（如 BGV/BFV 的有限深度版本）支持有限次数的加乘混合；全同态 FHE（2009 年 Gentry 之后）理论上支持任意电路，靠"自举"刷新噪声。能力递增的代价是开销递增——FHE 至今仍比明文慢三到六个数量级，这也是它在 MPC 系统里多当配角的原因。

零知识证明回答的是另一个问题：能不能证明"某命题成立"而不泄露任何额外信息？比如证明"我知道使得 H(x) 等于这个值的 x"，却不说 x 是什么。它有三性质：完备性（真命题能说服验证者）、可靠性（假命题几乎无法蒙混）、零知识性（验证者除命题真伪外一无所获）。在 MPC 语境里 ZKP 很少唱主角，它的戏份是补信任缺口：证明自己提交的输入合法、证明自己按协议计算、证明预处理材料没被做手脚。

一张分工表说清三者关系

混合协议是常态而非例外。举两个真实用法：其一，SPDZ 系的预处理可用加法同态的 Paillier 来造 Beaver 三元组——参与方各自用 HE 加密随机掩码并做同态乘，省掉昂贵的在线交互，把开销挪到可提前执行的预处理阶段（5.1 节展开）；其二，恶意模型下让每个参与方对自己的消息附一个 ZKP，证明"这条消息确实是按协议从合法输入算出来的"，作弊面立刻收窄（5.2 节的替代方案）。

动手演算：Paillier 加法同态的最小例子

拿小参数体会"密文相加等于明文相加"。设素数 p = 101、q = 103，n = p·q = 10403，选 g = n。明文空间模 n 方，随机数 r 取自模 n 方的可逆元。公钥 (n, g)，加密 E(m, r) = g^m · r^n mod n²。取 m1 = 15、m2 = 22：

p, q = 101, 103
n = p * q                 # 10403
g = n
n2 = n * n

def enc(m, r):
    return pow(g, m, n2) * pow(r, n, n2) % n2

c1, c2 = enc(15, 7), enc(22, 3)
c_sum = c1 * c2 % n2      # 密文相乘 = 明文相加（同态性）
# 解密后 c_sum 对应明文 37 = 15 + 22；而 r 的选择让两条密文毫无关联
​

会话行为：c1 与 c2 是两个毫无规律的巨型整数，相乘得到的 c_sum 解密后恰是 37。全程没有一方"看到" 15 或 22 的明文——这就是 HE 与 MPC 哲学相通的地方：运算在加密域完成。差别在于 HE 只有一把解密钥匙，MPC 则连钥匙都拆成了份额。

何时轮到它们出场

三个判断口诀。要"加密数据放在别人服务器上算"且只有一方出数据：HE 单挑即可，不必上 MPC。要"多方算且互相不信任"：MPC 主场，HE 退到预处理里帮忙。要"向外界证明计算没作弊"：ZKP 补位。反过来的错误示范也别犯：拿 FHE 硬跑多方计算——多方场景里 FHE 解不开"解密钥匙归谁"的死结，最后还是得靠门限解密或多轮交互，绕一圈回到 MPC。

⚠️ 常见坑：把"同态"听成"安全"。同态性只是"能在密文上运算"的代数性质，方案安全还依赖语义安全条件（加密随机化）。同样，ZKP 的零知识是相对验证者的，公开链上部署时还要防泄露元数据。

本节要点：HE 的三档能力与开销阶梯；ZKP 的三性质与补位角色；混合协议中三者各司其职。工具箱到此备齐——第 3 章进入第一条完整协议路线：混淆电路。

三选一的快速判断流程

遇到"该用哪样"的讨论，按顺序问三个问题。第一问：参与方有几家、互信程度如何？单方数据托管计算选 HE，互不信任的多方选 MPC。第二问：要向第三方证明什么？要证明计算没作弊、输入合法，加 ZKP；要证明统计结果不泄个体，加 DP；什么都不用对外证明就别加，纯白花钱。第三问：交互条件允许几轮？弱网环境优先少轮数方案，局域网可以接受多轮交互换低通信。三问之后方案的形状基本确定，剩下的差异属于工程细节。

最后补一个真实世界的注脚：秘密分享与 OT 的原始论文都在上世纪八十年代发表，全同态加密在 2009 年才出现，简洁零知识证明的实用化更是最近几年的事——理论等了几十年才等来算力与需求的东风。今天入行的人恰好站在工程化的窗口期，这算是这门手艺最好的时代注脚。

混编时代的技术素养清单

既然混合是常态，团队的技术素养要求也随之改变。按重要性排四条。第一，会写威胁模型：这是所有选型的起点，也是区分"工程师"与"技术买家"的分水岭——写得清"防谁、防到什么程度、放弃什么"，方案讨论才有锚点。第二，会算性能账：不需要会实现 Paillier，但要知道"Paillier 一次同态乘大约毫秒级、AES 一次微秒级"，量级感足够排除九成的错误方案。第三，会读安全声明的言外之意："金融级安全"没说模型档位，"军用级加密"没说密钥管理，"通过等保"与抵抗参与方作弊是两回事——声明缺省的部分往往比声明本身信息量大。第四，保持对标准化的敏感：隐私计算的互联互通标准在逐步推进，早期跟标准的框架将在生态整合中获得红利。

四条素养有一个共同底座：把每种技术看成"一份带价格的信任合同"，而不是"一个算法"。这份视角贯穿全书——第 5 章的安全模型是合同的条款页，第 6 章的性能账本是价格页，第 7 章的行业落地是合同的应用场景。读完本章，工具箱的五件武器你已经全部上手过，接下来进入把它们串成完整流水线的协议世界。