最近在整理隐私计算这块的笔记正好把全同态加密Fully Homomorphic Encryption简称FHE这条线从概念到落地实践系统地过了一遍。写这篇东西的初衷很简单我发现网上讲FHE的资料要么是纯学术论文风格的数学推导要么是几句新闻式的介绍就没了真正能让人从“为什么需要它”一路走到“我该怎么上手跑起来”的内容非常少。所以这篇系列的第一篇我把FHE最核心的骨架拆出来讲清楚它解决了什么根本性的矛盾、核心思想和经典方案是什么、当前工程上能跑到什么程度、以及怎么用开源库在一个小时内跑通第一个密文计算程序。如果你之前完全没接触过FHE读完这篇应该能建立起一个清晰的认知框架如果你已经有些了解这篇也可以帮你把零散的知识点串成一条线。后续系列里再深入到具体方案的数学实现和工程优化时你就能跟上节奏了。1. 全同态加密到底解决的是什么问题1.1 传统加密方式下“锁”和“算”是矛盾的我们先看一个特别常见的场景。假设你是一家医院的IT负责人想把历史病历数据上传到云端做统计分析但是数据涉及患者隐私肯定不能直接传明文。常规做法是用AES或者RSA把数据加密拿到key的人才能解密。可是问题来了云端拿到的是密文它没法在密文上直接执行“统计平均年龄”“统计某个区域发病率”这类计算得先解密成明文再统计。这就产生了一个根本性的矛盾加密保护了隐私但数据一旦加密就“死”了无法参与任何计算。传统做法是解密到可信环境里算完再加密但一旦解密明文就暴露给了计算方。如果计算方不可信或者计算环境被攻破隐私就全部泄露了。全同态加密干的事就是让云端的服务器在“没见过明文”的情况下直接在密文上完成整个计算过程。云端跑完结果给你你用自己的密钥一解密得到的结果和直接拿明文计算的结果完全一致。中间没有任何一步需要把数据还原成明文。这个特性用一句话概括就是加密状态下对数据做任意计算解密后结果与明文直接计算一致。这也是“同态”这个词的含义——某种数学结构经过加密和计算之后还能保持对应关系。1.2 全同态加密中的“角色分工”为了后面讨论方便先把FHE场景里的几个角色说清楚数据拥有者手里有数据加密后交给计算方手里保留私钥。计算方接收密文执行同态计算加法、乘法、比较等但全程看不到明文。结果接收者拿到计算结果密文用私钥解密得到最终明文。你会发现数据拥有者和结果接收者通常是同一个实体。如果有多个参与方还需要考虑密钥共享、数据分发的问题这属于安全多方计算和FHE结合的范畴以后的篇幅再展开。做个生活化类比传统加密相当于把数据放进一个上了锁的保险箱任何人都打不开但想加工里面的数据必须先开锁。而全同态加密相当于一个透明但“焊死”的加工车间外面的人可以看到整个加工过程但碰不到原件你扔进去的是半成品原料出来的是一批全新的成品整个过程车间里的人不需要打开保险箱。车间里的人虽然能看见原料的形状和加工过程但他没法直接改变你的原料他只能按照你设定的程序加工。这个类比不完全严谨FHE并不要求计算方看到内容实际上计算方看到的始终是密文但它能帮你理解“密文直接参与计算”这个核心差异。1.3 三次加密范式演进从“传得安全”到“用得安全”再从密码学历史角度看这个问题。早期的加密目标是让数据在传输过程中不可读比如HTTP改成HTTPS保护的是链路。这是第一类范式传输安全。后来数据要存起来不能永远只是中间经过一下于是加密存储、磁盘加密这类技术大规模应用保护的是静态数据。这是第二类范式存储安全。但到了云计算、数据协作时代数据的价值在于被使用——被统计、被训练、被查询。如果我们希望数据在“被第三方使用”的过程中也是安全的那就需要第三类范式计算安全。也就是让第三方在看不到明文的情况下完成计算。全同态加密正是计算安全这条线里最强的一种工具。它不限制计算类型、不限制计算深度理论上可以在密文上做任意可计算函数。也正因如此它被密码学界称为“密码学的圣杯”。2. 从部分同态到全同态这条路是怎么走过来的2.1 最早的“意外发现”RSA和Paillier同态加密思想并不是2009年才出现的。1978年Rivest、Adleman和Dertouzos在提出公钥密码体系不久后就正式提出了“隐私同态”这个概念。但真正意义上的第一个同态加密方案其实是RSA。RSA加密满足一个性质两个密文相乘再解密等于两个明文相乘。也就是说Dec(E(a) * E(b)) a * b这在数学上叫乘法同态。后来1999年Paillier加密方案满足加法同态Dec(E(a) * E(b)) a b等等你要注意Paillier的密文乘法对应的是明文加法但没关系关键是它能支持同态加法运算。这些方案统称部分同态加密Partially Homomorphic EncryptionPHE。它们的问题很明显只支持一种运算。现实世界的计算几乎不可能只用加法或只用乘法完成。你做一个简单的统计“总收入减去总成本”就需要同时支持加法和减法减法可以看成加负数而一般统计模型还需要乘法、比较、逻辑判断等操作。PHE根本应付不来。后来又发展出一类“Somewhat Homomorphic Encryption”近似同态加密SHE能够同时支持有限次数的加法和乘法比如Boneh-Goh-Nissim方案可以支持任意加法加上一次乘法。但深度再上去就不行了。2.2 转折点Gentry 2009年的大突破2009年还是斯坦福博士生的Craig Gentry在他的博士论文里提出了第一个全同态加密方案这也是密码学界公认的里程碑。他最大的贡献是给出了一个通用框架让任何满足特定性质的SHE方案都能“升级”成全同态方案。这个框架的核心就是Bootstrapping自举。Gentry的思路其实很巧妙。SHE只能算有限深度是因为每做一次乘法密文里的噪声就会变大噪声大到一定程度解密就会出错。那如果在噪声还没爆掉之前把解密电路本身也做一次同态计算呢也就是说构造一个“解密电路的密文版本”输入是当前密文输出是噪声被压缩回初始水平的新密文。这样就能“重置”噪声然后继续计算。这个操作就叫Bootstrapping。它本质上是用计算换噪声控制非常耗算力。Gentry当年的方案跑一个简单的运算需要几十分钟甚至更久离实用差得很远。但方向被验证了全同态加密在理论上是可行的。还有一个类比在密码学界很经典把同态加密里的噪声想像成房间里的灰尘。每次运算都会扬起灰尘灰尘太多你就没法继续在房间里工作。Bootstrapping相当于换了一套“全自动清洁系统”每计算一定次数就自动把房间清扫一遍让灰尘回到初始水平你就能无限期地继续工作下去。只是这套清洁系统本身也很费电。2.3 近十年的主流方案BGV、BFV、CKKS、TFHEGentry之后全同态加密经历了非常快的发展目前学术界和工业界主流使用的方案大致分四类BGVBrakerski-Gentry-Vaikuntanathan2011基于格上的LWE/RLWE问题支持模数链和Leveled FHE适合整数算术在很多库里有实现。BFVBrakerski-Fan-Vercauteren2012和BGV核心思想类似把明文空间放在模数上直接编码整数运算语义直观目前工业落地最多的方案之一。Microsoft SEAL、OpenFHE里都有BFV。CKKSCheon-Kim-Kim-Song2017面向实数运算允许计算结果有一个小的近似误差特别适合机器学习、信号处理等不需要精确整数结果的场景。但这意味着解密出来的结果是“近似正确”的设计业务时要留意精度问题。TFHEChillotti-Gama-Georgieva-Izabachène2016基于bootstrapping优化的方案速度极快可以把任意布尔电路做同态化适合做加密比较、数据库查询等基于bit逻辑的场景。TFHE的bootstrapping以毫秒级著称。这里有个概念需要区分BFV和BGV通常称为Leveled FHE——它们可以不依赖Bootstrapping在预设好深度的前提下做有限次数的密文运算如果需要无限深度则在超过深度时激活Bootstrapping。CKKS也是一种Leveled FHE方案TFHE则把bootstrapping做成了核心操作几乎每个算子在跑完以后都会自动刷新噪声。下面这张表整理了四种方案的核心差异方案支持的数据误差典型优势典型场景BGV整数无模数链设计灵活整数计算效率高通用密文计算BFV整数无明文编码直观易于工程实现数据库统计、密文查询CKKS浮点数/复数有近似误差精度可控适合实数运算机器学习、信号处理TFHE比特布尔电路无bootstrapping快支持快速门电路加密搜索、比较、条件分支选型建议在后面的实操和工程章节再细讲这里只需要记住一个结论没有“最好的FHE方案”只有“最适合当前场景的方案”。3. FHE的核心机制噪声、格、自举3.1 为什么会有噪声要理解FHE的工程实现绕不开噪声noise这个概念。几乎所有现代FHE方案都基于格密码困难问题最常见的是LWELearning With Errors和它的环变体RLWE。RLWE的加密形式大概是这样的概念把消息m“埋”到一个多项式里然后加上随机误差e生成密文。解密的时候由于误差的存在我们不能直接读出消息只能通过舍入/模运算把误差消除后得到消息。只要误差在某个可允许范围内解密就是正确的。但是一旦噪声超过临界值消息就会被噪声完全淹没解密就会出错。这就是FHE最核心的工程约束噪声增长不能超过阈值。3.2 加法是温和的乘法是爆炸的不同类型运算对噪声的放大效果天差地别。同态加法两个密文相加噪声也近似相加。通常噪声增加是线性的很小。同态乘法两个密文相乘噪声会互相放大。如果每一项噪声是e乘法后的噪声大约是e乘以e的量级也就是平方级别的增长。所以一个只做加法的计算任务即使深度很深噪声压力也不大但只要连续做几次乘法噪声就指数级飙升很快就会突破可解密的阈值。这解释了为什么SHE方案能支持“有限深度的电路”——深度越大噪声累积越快。这里有一个非常重要的实际结论你在设计FHE计算流程时要尽可能减少连续乘法的深度。比如多个数连乘可以通过分批乘法、近似算法等手段来降低深度否则每一步的噪声都会让后续计算变得非常昂贵甚至失败。3.3 Bootstrapping给噪声“重置”前面提到Bootstrapping就是在密文上运行解密电路从而刷新噪声。具体一点说假设你手里有一个密文c它对应的明文是m当前噪声是EE已经比较大了。你自己当然可以用私钥sk解密得到m但这一步是在明文上做的不满足需求。Bootstrapping的做法是把解密过程本身变成一个同态计算。也就是说把私钥sk加密成密文然后同态地执行“用这个加密后的sk去解密c”。这个过程完成后得到的新密文c也是m的密文但它的噪声被重置到了比E更低的状态。听起来很神奇但它确实实现了“在不知道明文的情况下重置密文的噪声”。代价是什么计算开销极高。你需要把解密电路里所有操作都转化成同态运算整个Bootstrapping过程本身就要执行大量的密文乘法和加法。虽然现代方案已经把Bootstrapping优化到秒级甚至毫秒级尤其是TFHE但相比明文计算的代价仍然是几个数量级的差距。还有一个细节不是所有FHE方案都必须Bootstrapping。如果你预先知道计算深度并且愿意为这个深度预设足够的参数更大的模数、更大的多项式度数那就可以在深度范围内完成计算而不需要Bootstrapping。这被称为Leveled FHE。它的优点是省去了自举开销缺点是参数会随着深度变大而膨胀计算效率下降。实际应用中很多团队会优先采用“Leveled模式少量自举”的混合策略。3.4 理解FHE的三大经典操作抛开具体数学FHE系统的基本操作可以归结为三大部分KeyGen生成密钥对。通常包含公钥pk、私钥sk有时候还有计算密钥Evaluation Key和重线性化密钥Relinearization Key。这几个扩展密钥都是为了降低某些操作的噪声或者约束密文规模。Enc/Dec加密和解密。加密通常把消息映射到多项式域上的明文空间加上随机数。解密则从密文中提取消息并舍入掉噪声。Eval同态计算。这是FHE的核心包括同态加法EvalAdd、同态乘法EvalMult、同态重线性化、同态置换等。每一步都可能触发噪声增长工程上会对特定的运算调用降噪操作。加密过程还有一个细节为了保证安全性加密算法必须是概率性的。也就是说同一个明文每次加密得到的密文都是不同的。这让我第一次接触FHE的时候懵了好久——两次加密同一个数字5密文完全不一样但解密都是5。原因就是每次加密都会独立采样随机噪声密文自然不同。只要噪声在范围内解密就能正确恢复明文。4. 工程实践FHE现在的真实效率与主流工具4.1 性能现状慢是慢但已经有实用窗口很多人一听FHE第一反应就是“太慢工业上没法用”。这个印象在2015年之前基本成立但近几年变化非常快。现在的水平大致是这样的以公开测试数据和我的实测经验为参考同态加法毫秒级以下基本可以忽略性能焦虑。同态乘法毫秒到几十毫秒级别取决于安全级别和多项式度数。TFHE的bootstrapping单次大约10毫秒到几十毫秒足以支持门级电路的实时计算。CKKS做同态矩阵乘法对于中小规模矩阵已经可以做到秒级甚至更快。也就是说如果把明文计算需要的时间定义为T那么FHE的典型开销在10^2到10^6之间具体取决于运算类型和参数。对于简单的统计求和、均值计算这类“加法和少量乘法”的任务开销可能就在几百倍左右这已经可以接受对于需要大量连续多项式乘积的深度学习推理开销可能会非常惊人需要用SIMD编码、批处理、多种优化手段来把性能拉回来。所以我的看法是FHE现在不是“能不能用”的问题而是“在哪些场景值得用”的问题。如果一个业务痛点足够大——比如医疗数据隐私协作、金融风控数据的跨机构融合——那么付出几百倍的计算开销换来的数据安全是划算的如果你只是给自己服务器上的MySQL做点统计那完全没必要上FHE。4.2 常用开源库与选型建议这里整理了目前社区使用最广泛、维护最活跃的几个FHE库库支持方案语言维护方适合场景Microsoft SEALBFV、CKKSC/C#微软商业项目、工业落地OpenFHEBGV、BFV、CKKS、TFHECOpenFHE社区需要多方案对比的研究项目HElibBGV、CKKSCIBM学术研究和批处理场景TFHETFHE布尔电路C/C/RustZama等门电路快速运算PyfhelBFV、CKKS等Python社区快速原型验证、教学TenSEALBFV、CKKSPythonOpenMined和PyTorch生态结合的隐私计算选型上有几个经验可以参考如果你想做机器学习推理、向量计算优先看CKKSPyfhel/TenSEAL里都有成熟封装。如果你想做精确整数运算、密文数据库查询选BFVMicrosoft SEAL的文档写得很详细。如果你想做非常复杂的依赖条件分支的逻辑判断比如“如果年龄大于18则通过”这种优先考虑TFHE。如果只是想在几天内验证FHE在你的业务里是否可行不要直接上C先用Python包装好的库跑原型。4.3 应用场景盘点FHE目前已经有一批实际落地的场景我列几个我认为最值得关注的医疗数据协作多家医院共享统计模型训练数据但彼此不允许看到原始个体数据。FHE可以让模型更新在密文上完成。金融反欺诈和信用评估银行之间需要共享黑名单或用户风险评分逻辑但不想暴露自己的数据规则。FHE可以在密文上执行规则匹配和评分。私有信息检索PIR从数据库里查询某条记录而不让数据库知道查了什么FHEPIR是当前效率较好的方案之一。安全多方计算中的计算引擎FHE可以作为MPC引擎的内部实现模块多个参与方把数据加密后交给一个不信任的计算节点做计算。机器学习的隐私保护推理云端拿到的加密输入运行一个加密过的模型推理。常见做法是把模型权重加密在服务端把用户输入加密传上来在密文上跑一次推理输出加密结果给用户。要提醒一句FHE不是万能药。它保护的是“计算过程中数据的机密性”。如果你的业务风险在于“接收方拿到结果后滥用信息”或者“某参与方故意输入错误数据”FHE解决不了这些社会工程学层面的问题需要通过协议审计、结果验证、区块链存证等手段来补充。5. 实操入门用Pyfhel跑通第一个FHE密文计算5.1 环境准备与安装为了快速体验FHE我推荐用Python的Pyfhel库。它不仅封装了底层C实现底层依赖SEAL/OpenFHE语法也接近明文计算特别适合原型验证。安装很简单pip install pyfhel建议在Python 3.8到3.11环境下安装。如果碰到build失败大概率是缺少C编译链Windows下装一下Visual Studio Build ToolsLinux下装build-essential就行。5.2 第一个例子两个整数的同态加法下面我写一个最简单的BFV方案示例完成两个整数a、b的加密、同态加法、解密并验证结果。from pyfhel import Pyfhel, BFV # 1. 初始化BFV方案的上下文 HE Pyfhel() context BFV(poly_modulus_degree4096, plain_modulus65537) HE.contextGen(context) # 2. 生成密钥公钥、私钥、计算密钥 HE.keyGen() HE.relinKeyGen() # 3. 加密两个整数 a 12 b 30 ct_a HE.encryptInt(a) ct_b HE.encryptInt(b) # 4. 同态加法两个密文相加 ct_sum ct_a ct_b # 5. 解密 result HE.decryptInt(ct_sum) print(f明文加法结果: {a b}) print(f密文同态加法结果: {result}) print(f密文不等于明文: {ct_sum ! a b}) # 这是密文对象不能直接与整数比较输出结果明文加法结果: 42 密文同态加法结果: 42这里的核心就三行encryptInt把明文变成密文运算符执行同态加法decryptInt把密文解密成明文。你可能会觉得这也太简单了但真正的FHE计算在底层做了非常多的事包括多项式运算、噪声管理、重线性化等。Pyfhel把这些都封装好了。5.3 第二个例子加密状态下的混合运算接着再看乘法和混合运算。from pyfhel import Pyfhel, BFV HE Pyfhel() context BFV(poly_modulus_degree4096, plain_modulus65537) HE.contextGen(context) HE.keyGen() HE.relinKeyGen() # 加密三个整数 x 7 y 3 z 5 ct_x HE.encryptInt(x) ct_y HE.encryptInt(y) ct_z HE.encryptInt(z) # 计算 x*y z ct_result (ct_x * ct_y) ct_z result HE.decryptInt(ct_result) print(f明文计算结果: {x * y z}) print(f密文计算结果: {result})输出结果明文计算结果: 26 密文计算结果: 26这个例子里我在密文上做了乘法又做了加法。每一步运算之后密文的噪声都在增长。如果后续还继续乘很多次你就需要考虑更深度的参数、更大的plain_modulus或者在适当时候做重线性化和重新加密。5.4 关键参数怎么选poly_modulus_degree和plain_modulus刚开始跑FHE最容易被两个参数卡住poly_modulus_degree和plain_modulus。我用自己的踩坑经验说明一下。poly_modulus_degree也常写成N决定了密文的维度和多项式的次数直接影响安全强度和密文大小。常见值是4096、8192、16384、32768。N越大能支撑的计算深度越大但同时密钥和密文越大运算越慢。4096适合做少量加法和少量乘法的简单场景要跑比较深度的计算至少要8192起。plain_modulus明文模数代表明文空间的大小。明文值必须在0到plain_modulus-1之间。更重要的是它和噪声容限有直接关系plain_modulus越小允许的噪声空间越大能支撑的运算深度越大plain_modulus越大噪声容限越小运算深度受限。所以在BFV里你常常看到人们为了深度把一个较小的plain_modulus选成质数比如65537。建议初学者一开始不要追求大参数先用poly_modulus_degree4096、plain_modulus65537跑通再逐步增大poly_modulus_degree测试复杂计算。当你测试乘法深度时如果报了解密错误先别怀疑代码大概率是噪声爆了——这时候优先调大poly_modulus_degree或减小plain_modulus。Pyfhel里上下文还包含一个ciphertext modulus链coefficient_modulus通常不需要手动指定库会基于poly_modulus_degree和plain_modulus自动生成。但如果你希望更精细控制性能与安全级别建议去阅读OpenFHE的文档配置标准化的模数链。5.5 写代码时的注意事项Pyfhel虽然用起来像明文运算但有些细节完全不一样我踩过不少坑密文对象不能重复使用到另一个上下文里。一个上下文生成的密文只能由同一个上下文解密。别想当然地把密文存下来换个进程解密。同态乘法之后密文的大小ciphertext size会增大通常需要调用重线性化relin压缩回来否则后续乘法会更慢甚至无法继续。Pyfhel的乘法运算符内部已经自动重线性化了但你如果直接用底层操作记得调用relinKeyGen生成重线性化密钥。明文空间有限。如果明文值接近plain_modulus算完之后解密可能会得到溢出结果。这在整数运算中尤其明显。所以设计业务时要对明文的最大可能值做预估。如果你要加密的是浮点数用CKKS方案而不是BFV。CKKS的API在Pyfhel里对应encryptFrac能够保持精度但会有微小误差。6. 常见问题与排查技巧实录下面这些问题是初学者问得最多、我也实际踩过的整理成一张速查表。现象可能原因排查与解决思路解密结果不是预期的整数噪声过大导致密文解密失败增大poly_modulus_degree或减小plain_modulus或减少乘法深度程序跑得很慢几分钟没反应poly_modulus_degree太大或乘法链太长将poly_modulus_degree降到8192以下检查乘法深度评估是否可以用加法替代部分乘法同态乘法后报错乘法导致密文规模增长超出当前上下文确认当前上下文支持乘法手动调用relinearization检查是否已经生成relin密钥密文保存到硬盘后无法解密上下文参数尤其是系数模数与解密时不一致保存密文时同时保存HE上下文解密时加载同一个上下文CKKS解密结果精度不对方案是近似计算本身就有误差调整精度参数使用更合适的scale系数对结果做后处理明文中出现负数时结果不对明文空间是有限域负数会被映射到模空间在加密前对方言进行偏移或使用CKKS方案支持浮点或选择合适明文模数搞不清选哪个方案场景需求不明确整数精确计算用BFV浮点近似计算用CKKS逻辑判断/比较用TFHE单独说一个非常隐蔽的问题明文空间负数的处理。BFV的明文空间是模plain_modulus的有限域在模运算下负数会和它的补数一起参与计算。比如plain_modulus65537时-5在这个空间里等价于65532。如果你直接加密-5解密有可能得到65532而不是-5。解决方案就是选择合适的明文范围映射要么在业务层把明文整体平移所有数加一个偏移量算完再减回来要么使用CKKS方案用浮点数天然支持符号。另外一个特别实用的经验在生产环境部署FHE一定要保存好“参数指纹”。我遇到过几次麻烦开发机上跑得好好的一批密文换到服务器上加载就报错最后发现是两边的参数版本不一致。建议把HE上下文序列化之后和密文一起保存或者至少把poly_modulus_degree、plain_modulus、coefficient_modulus这些参数写进数据库配置表。对了同态加密的密文通常是公钥密码体系下的产物在传输和存储过程中一般不需要再额外加密但如果你做了多层加密比如TLS通道里传密文也不会有什么问题只是会浪费一点性能。结个尾顺带讲讲这个系列后面打算写什么说实话FHE这个东西第一眼看上去全是数学挺劝退的。但如果你像我一样从“到底解决什么问题”出发把它放到云计算、隐私计算、多方协作这些大的语境里看你会意识到这个技术解决的是一个绕不过去的刚需数据不能在你不可控的环境里裸奔但它又必须被那台机器用来计算。我个人在实际操作中的体会是想用好FHE核心不是背公式而是建立三层认知——第一层是知道它解决了什么问题第二层是理解噪声、自举、参数这些工程概念第三层是能把具体业务场景翻译成“加法和乘法电路”的深度。所以这个系列的第01篇先搭框架后续我会接着拆几种主flow方案的数学细节、Bootstrapping的具体实现、如何在C工程里调优性能、以及CKKS在机器学习推理里的完整落地案例。还有一些我准备展开的细节比如怎么用SIMD批处理来榨干CKKS的吞吐能力、BFV和CKKS的编码方式到底差在哪、如何在FHE密文上做比较和分支操作。如果这篇能帮你顺利迈出第一步那我的目的就达到了。下一篇我们直接上手做一个“在密文上跑线性回归”的小项目把今天这些概念全部落地一遍。
