同态加密：云替你算，却看不见你的数，代价是服务器跑了一整夜

去年秋天，南京连着下了半个月的雨。我在机房蹲到凌晨两点，盯着一台服务器跑同态加密的演示程序。屏幕上的进度条跟停了差不多。旁边的同事啃着鸭脖问我：这玩意儿到底行不行？我说行，就是有点费电。

那个项目是医疗数据联合建模。甲方要求很明确：数据不出医院，但模型要一起训。我们提了三种方案，MPC、TEE、同态加密。甲方一听同态加密眼睛就亮了——“密文直接算，中间不解密，这不就是科幻片里的东西吗”。我心里咯噔一下。科幻片里的东西，通常都挺贵的。

先把“同态”这两个字拆开看

同态，homomorphic，说白了就是运算顺序可以换。

你对明文做加法，我对着密文做加法，解密出来的结果是一样的。写成式子大概是 E(a) ⊕ E(b) = E(a+b)，那个 ⊕ 不是普通的加，是“密文空间里的某种操作”。这就是加法同态。

乘法同态同理。两个都支持，叫全同态，Fully Homomorphic Encryption，简称 FHE。

这事不新鲜。1978 年 Rivest 他们几个人就提过“隐私同态”的设想，那会儿 RSA 刚出来没多久。后来几十年，大家只能做到“半同态”——RSA 能乘不能加，Paillier 能加不能乘。你要算个多项式，得在加法和乘法之间反复横跳，跳着跳着就卡死了。真正的转折点是 2009 年，Gentry 的博士论文用理想格构造出了第一个全同态方案，还顺手发明了一个叫“自举”的东西。那年密码学圈子炸了锅，因为这意味着理论上你能把任意计算搬到密文上。

理论上。

问题出在“噪声”上。

你把明文加密成密文，密文里其实掺了一层“噪声”。这东西就像给易碎品裹的泡沫。你每做一次密文运算，泡沫就被压扁一点。加一次扁一点，乘一次扁一大截。扁到某个阈值以下，解密就会出错；再扁下去，密文会变得“透明”——意思是它的分布跟随机数没区别了，安全性直接崩。

同态加密CKKS密文噪声预算随乘法深度下降曲线图

所以早期方案只能算有限深度的电路，业内叫 leveled FHE，分层同态。想算得深，就得把参数调大，密文跟着膨胀，速度跟着塌方。

Gentry 的自举就是来救场的：在密文上重新做一次解密，把被压扁的噪声“捋”回初始状态。听起来很玄，其实就是把解密电路本身也加密了，然后同态地跑一遍。跑完之后噪声刷新，你可以接着算。代价嘛——自举一次的开销，比普通乘法高一到两个数量级，参数不调好的话能高三个数量级。

全同态加密Bootstrapping自举刷新噪声流程示意图

现在主流的几个方案，分工挺明确。BFV、BGV 做精确整数运算，适合计数、匹配这类不能有误差的场景。CKKS 做近似浮点，天生为机器学习准备，代价是结果有微小误差。TFHE 走布尔门路线，单个门快得离谱，适合做比较、查表这类逻辑密集的活。你选错了方案，就像拿螺丝刀去砸钉子，能干，但很别扭。

参数选错的那一刻，我听见了钱烧掉的声音

参数选错的那一刻，我听见了钱烧掉的声音

说回机房那一晚。

我们用的是 CKKS，多项式阶数 N 取 16384。什么概念？一个密文大概是几百 KB 到一两兆，具体看模数链的长度。我头一次看到这个数字的时候愣了一下——TLS 握手传的那点东西跟它比，简直不值一提。

单次密文乘法，单线程，几十毫秒到一百多毫秒。你可能觉得还行。但神经网络里一层矩阵乘就是成千上万次乘加，还得算上旋转（rotation）操作——把密文里的向量循环移位，用来做卷积和全连接。旋转本身不难，难的是它需要“密钥切换”，又是一笔开销。

我们那个模型不大，十来层，跑完一轮推理用了四十多分钟。明文版本多少？不到两秒。

两千倍。这还只是推理。

真正拖后腿的是通信。批量推理，一次打包一千个样本，每个样本单独加密，光上传就传了几百兆。客户那边的专线带宽有限，传完之后我发现，瓶颈根本不在算力，在网线。

还有个坑我印象特别深。某次跑着跑着程序抛异常，日志里一行字：transparent ciphertext。翻译过来就是“你的密文已经透明了”。我当时一头雾水，后来才明白，是噪声预算耗尽了，密文退化成了明文可恢复的状态。这不是性能问题，这是安全问题。参数估算错了，你以为在算数，其实在裸奔。

顺便说一句，噪声预算这个东西，SEAL 里能看到具体还剩多少 bit。初始可能一两百 bit，一次乘法掉几十 bit，几次之后就见底。所以工程上头一件事不是写算法，是拿计算器算深度。

它能落地的地方，比你想的窄，也比你想的深

我不太喜欢那种“同态加密将重塑一切”的论调。它是个工具，工具有它的尺寸。

真正跑起来的场景，往往有个共同特征：计算方不能看数据，但又必须做实质性的计算。

比如医疗。两家医院想联合统计某种病的发生率，谁也不想把病人记录给对方。这种场景其实用安全多方计算或者 PSI 更划算。但如果要做的是“在加密状态下跑一个影像分类模型”，那就得靠同态加密了，因为模型权重和输入都得保密，中间还不能解密。

再比如金融。风控模型要查黑名单，名单在对方手里，你不想暴露查询对象，对方不想暴露名单。集合小的时候用 PSI，集合大、逻辑复杂的时候才轮到 FHE。我见过一些方案书，一上来就写“采用全同态加密实现隐私求交”，我一般会问一句：你们算过通信量吗？对面通常沉默。

还有一类是外包计算。小公司没有算力，把加密数据丢给云，云端算完返回密文结果。这个模式在理论上非常优雅，在工程上非常让人心疼。云厂商按算力收费，同态加密的算力消耗是明文的几百上千倍，账单一出来，优雅就没了。

隐私计算同态加密云端外包计算联合建模系统架构图

说到误区，有几个我反复跟人解释。

同态加密不保证结果正确。 它保证的是“计算过程看不见数据”，不保证“计算方老实”。恶意服务器给你返回一个乱算的密文，你解出来就是错的，而且很难发现。要防这个，得配上可验证计算或者冗余校验，成本再翻一倍。

它也不防侧信道。 访问模式、时序、内存占用，这些都能泄露信息。你加密了数据，但没加密“你什么时候查了哪一行”。ORAM 这类技术能补，补完又是一层开销。

密钥管理是个大坑。 多密钥同态还在研究阶段，实际部署里往往是“一方持密钥、多方算密文”，密钥一丢，全盘皆输。而且同态加密的密钥比普通对称密钥大得多，分发和轮换都麻烦。

还有个常见误解：以为同态加密是“加密后什么都能干”。不是的。你加密之后能干的，是事先定义好的电路。想做动态查询、想跑任意 SQL，得先把查询编译成电路，这一步的工程复杂度经常被低估。

那我现在还会不会用它？

那我现在还会不会用它？

会。但得先过三道筛子。

先看一道：数据能不能脱敏、能不能加差分隐私、能不能干脆不出域只传梯度？能，就别碰 FHE。它是重武器，杀鸡用重武器，鸡死了，钱包也死了。

再看一道：参与方在不在线？在线的话，MPC 的延迟通常更友好；有可信硬件的话，TEE 的性能更接近明文。FHE 的优势在于计算方可以完全离线、异步、甚至不可信。这个优势很独特，但不是每个场景都需要。

还有一道：数据量和函数复杂度。小规模、固定函数、深度不高的场景，FHE 已经能打。大规模、动态逻辑、低延迟要求的，再等几年。

真要用，几个工程上的土办法：能 leveled 就别自举，自举是最后的救命稻草；把向量打包进密文的 slot 里做 SIMD，一个密文算几千个数，能省下大量重复开销；参数按电路深度反推，别拍脑袋；通信层做压缩和批处理，否则网络先崩。

硬件这边也在动。GPU 加速 NTT、FPGA 做模乘、专用芯片把自举塞进流水线，这些年陆续有进展。等哪天自举从“几秒”掉到“几毫秒”，整个局面会不一样。

那天凌晨两点多，结果终于出来了。我拿明文结果对了一遍，误差在 1e-6 这个量级，在预期之内。我盯着屏幕看了会儿，有点想笑。它是真的能算。只是太贵了。

贵到什么程度呢？贵到你必须在方案书里单独列一行“隐私计算资源预算”，贵到客户看完报价会沉默三秒。

不过话说回来，HTTPS 刚出来那会儿，大家也嫌它慢。后来有了专用指令、有了会话复用、有了 CDN 卸载，它就成了默认配置，没人再提。同态加密大概也会走这条路——不是因为它变神奇了，是因为电费和带宽变便宜了，工具链变顺手了。

到那时候，它不会出现在 PPT 的封面上。它会藏在你看不见的地方，安安静静地替你算着一些你不敢给人看的东西。