1. 项目概述为什么我们需要多密钥全同态加密如果你在数据安全、隐私计算或者云计算领域摸爬滚打过几年一定对“数据孤岛”和“数据可用不可见”这两个词深有感触。传统的加密技术比如AES、RSA能很好地解决数据静态存储和传输中的安全问题但一旦需要对加密数据进行计算就必须先解密——这瞬间就把数据暴露在了风险之中。全同态加密Fully Homomorphic Encryption, FHE的出现就像给数据穿上了“隐形斗篷”允许在密文上直接进行任意复杂的计算如加、乘而计算结果解密后与对明文直接计算的结果一致。这听起来简直是隐私计算的终极梦想。但现实往往更复杂。想象一个多方协作的医疗研究场景医院A有患者的基因组数据医院B有患者的临床病历研究机构C有药物反应模型。三方希望共同训练一个AI模型来预测疗效但谁都不愿意把自己的原始数据哪怕是加密后的交给对方。传统的单密钥FHE在这里就卡壳了因为它默认所有计算都发生在同一个密钥加密的数据上。如果数据来自不同方用不同密钥加密单密钥FHE就无能为力了。这就是“多密钥全同态加密”Multi-Key Fully Homomorphic Encryption, MK-FHE要解决的核心痛点。它不是一个简单的功能扩展而是FHE从“单机版”迈向“分布式协作版”的关键跃迁。MK-FHE允许多个参与方各自使用自己的私钥独立加密数据。这些由不同密钥加密的密文可以被汇聚到一个或多个计算节点上进行联合计算。最终只有所有相关参与方共同协作才能解密出正确的计算结果。这个过程中任何单一参与方包括计算节点都无法窥探其他方的原始数据。我最早接触这个概念是在设计一个跨金融机构的反欺诈联盟项目时当时单密钥方案在密钥管理和数据归属上遇到了无法调和矛盾直到研究了MK-FHE才找到出路。它不仅仅是技术的叠加更是一种全新的安全计算范式为联邦学习、安全多方计算、隐私保护云计算打开了新的大门。接下来我会结合自己的实践和理解拆解MK-FHE的核心原理、主流方案、实操难点以及那些在论文里不会写的“坑”。2. 核心原理从单密钥到多密钥发生了什么质变要理解MK-FHE必须从单密钥FHE的基础讲起。目前主流的FHE方案如BFV、BGV、CKKS大多基于格密码学中的“带误差学习”Learning With Errors, LWE问题或其环版本RLWE。其核心思想可以粗糙地类比为把数据明文m藏在一个高维格点密文c附近而密钥s就是这个高维空间的“特殊视角”。加密过程相当于给数据加上了大量随机噪声误差e使得c看起来完全随机。同态运算加/乘会操作这些密文但同时也会让累积的噪声急剧增长。FHE的魔法在于“自举”Bootstrapping操作它像是一个噪声“重置器”能在密文状态下将噪声水平降低从而支持任意深度的计算。2.1 单密钥FHE的协作瓶颈在单密钥FHE中所有计算都基于同一个公钥-私钥对(pk, sk)。数据拥有者用pk加密数据将密文发给计算方。计算方执行同态计算后将结果密文返回数据拥有者用自己的sk解密。这里有一个隐含的强信任假设所有待计算的数据都必须由同一个私钥sk的持有者或其完全信任的代理来加密。在多方场景下这意味着要么大家共用一个密钥密钥分发和管理是灾难且失去了数据主权要么必须把原始数据交给其中一方来统一加密违背了隐私初衷。2.2 MK-FHE的核心思想密文扩展与联合解密MK-FHE打破了这一限制。它的目标很明确允许密文c1由密钥sk1加密和密文c2由密钥sk2加密能够被一起计算。主流方案如基于GSW的MK-FHE以及后续的TFHE变种通常通过一个巧妙的“密文扩展”过程来实现。1. 密文扩展Ciphertext Extension这是最关键的一步。假设现有参与方A和B各自拥有密钥对(pk_a, sk_a)和(pk_b, sk_b)。A加密得到密文ct_aB加密得到密文ct_b。在计算之前需要将这些单密钥密文“转换”或“扩展”成一个与所有参与方密钥都相关的“联合密文”。一个典型的方法是构造一个大的“联合公钥”。例如在基于LWE的方案中每个参与方i的私钥sk_i是一个向量。联合公钥可以构造为所有公钥的某种张量积或连接。对一个密文进行扩展意味着将它重新加密在密文状态下成一个看起来像是用这个“联合公钥”加密的密文。这个过程本身也是同态完成的确保原始明文信息不泄露。2. 同态计算在扩展密文上进行一旦所有输入密文都被扩展为与同一组密钥{sk_1, ..., sk_n}相关的格式它们就变成了“同一种语言”。此时标准的FHE同态加法和乘法规则就可以直接应用在这些扩展密文上了。计算节点像处理单密钥FHE密文一样处理它们完全无需感知底层有多个密钥。3. 联合解密Joint Decryption计算完成后得到一个结果密文ct_result这个密文只能被所有相关参与方共同解密。解密不再是Dec(sk, ct)而是Dec(sk_1, sk_2, ..., sk_n, ct)。具体实现上通常需要每个参与方i使用自己的私钥sk_i对结果密文进行一个本地“部分解密”操作产生一个“部分解密份额”。然后将所有份额组合起来才能得到最终的明文结果。任何一方缺失解密都无法完成。注意这里的“联合”程度可以设计。有的是“全参与方”解密即初始的所有数据提供方都必须参与有的可以支持“门限解密”即n方中任意t方合作即可解密这增加了灵活性但也引入了更复杂的密钥管理。2.3 技术挑战与代价天下没有免费的午餐。MK-FHE的强大功能伴随着显著的代价密文膨胀扩展操作会使密文尺寸急剧增大通常与参与方数量N成线性甚至二次关系。这是MK-FHE最大的性能瓶颈。计算开销剧增对扩展后的大密文进行同态运算其计算复杂度远高于单密钥情况。通信成本扩展过程可能需要交互在某些非交互式方案中不需要而联合解密必然需要多方通信交换解密份额。密钥管理复杂虽然私钥仍由各方独立保管但联合公钥的生成、分发和更新需要安全的协议。理解这些原理我们就能明白MK-FHE不是一个“开关”而是一套权衡的艺术。在实际应用中我们往往需要根据参与方数量、计算复杂度、对延迟和带宽的容忍度来选择合适的方案和参数。3. 主流方案与工具选型实战中我们有哪些选择理论很丰满现实要落地。目前MK-FHE尚未像AES那样有标准化方案但学术界和工业界已经提出了多条技术路径并有了一些可用的开源库雏形。选择哪种方案直接决定了项目的可行性。3.1 基于GSW的MK-FHE方案这是最早提出且概念相对直观的MK-FHE方案之一。GSW方案本身密文就是矩阵形式其同态乘法是矩阵乘法天然具备一些扩展性。MK-FHE可以通过将多个参与方的密钥“捆绑”成一个大的块对角矩阵来实现。这类方案的优点是原理清晰但密文膨胀非常严重O(N^2)量级计算效率低目前主要用于理论研究和原型验证不太适合大规模生产环境。适用场景学术研究概念验证PoC参与方极少2-3方的简单计算场景。3.2 基于BFV/BGV的MK-FHE方案BFV和BGV是当前应用最广泛的FHE方案特别是在整数算术上。它们的MK-FHE变种通常采用“密文重线性化”和“密钥切换”技术的组合来实现密文扩展。基本思路是将一个密文在计算过程中动态地转换为对应于另一个密钥的密文。通过精心设计可以将这个过程推广到多个密钥。优点继承了BFV/BGV在整数计算上的效率和丰富的工程优化如RNS、模切换。有像Microsoft SEAL通过CKKS方案间接支持和OpenFHE这样的成熟库正在探索相关功能。缺点方案本身较为复杂参数设置非常考究联合解密协议需要仔细设计以避免安全问题。实操心得如果你已有的项目基于SEAL库做单密钥FHE想探索MK-FHE可以关注OpenFHE库的BGVrns或BFVrns方案中对多密钥的支持。你需要重点关注其“联合密钥生成”JointPublicKey和“密文重线性化密钥”RelinKey的生成与使用方式。参数设置时必须预留比单密钥模式大得多的密文模数和特殊模数以容纳扩展带来的噪声增长。3.3 基于CKKS的MK-FHE方案CKKS方案支持浮点数的近似计算是机器学习等应用的首选。其MK-FHE变种原理与BFV类似但需要处理近似计算带来的额外误差。这是目前工业界关注度最高的方向因为AI协作是MK-FHE最杀手级的应用。代表库OpenFHE对CKKS的多密钥支持相对活跃。LattigoGo语言也提供了多密钥CKKS的实现。这些库通常提供了高级API简化了多方密钥生成、密文扩展和联合解密的流程。关键对象在多密钥CKKS中你会频繁接触到MultiParty、JointPublicKey、Ciphertext其GetKeyID方法可以查看密文关联的密钥等对象。工具选型建议 对于大多数希望将MK-FHE应用于实际隐私计算项目的团队我建议的路径是首选OpenFHE它是一个集成了BFV、BGV、CKKS、FHEW/TFHE等多种方案的统一库对多密钥的支持最全面社区活跃文档和示例也在快速完善。其C接口性能高也提供了Python绑定。考虑Lattigo如果你的技术栈以Go为主或者需要开发高性能的分布式后端服务Lattigo是一个极佳的选择。它的API设计清晰多密钥示例也比较直观。谨慎使用纯理论实现GitHub上一些学术代码多为基于GSW的仅用于演示原理缺乏工程优化、安全审计和长期维护不建议用于生产。重要提示无论选择哪个库请务必使用其最新版本并仔细阅读关于多密钥部分的文档和单元测试。MK-FHE的API和功能仍在快速演进中。4. 实战演练构建一个简易的多密钥安全求和示例光说不练假把式。我们用一个最经典也是最基础的应用场景——安全求和Secure Sum来演示MK-FHE的完整工作流程。假设有三家公司各自有一组敏感的营收数据他们想计算三家的营收总和但不想泄露自己具体的数值。我们将使用OpenFHE库以CKKS方案为例来模拟这个过程。请注意以下代码为示意性伪代码重点在于阐述流程实际开发需参考OpenFHE官方示例。4.1 环境准备与参数设置首先所有参与方需要就FHE的“计算上下文”达成一致。这包括多项式环的维度ringDim、缩放因子scale、模数链moduli等。这些参数决定了计算的能力、精度和安全性等级。// 伪代码参数协商所有参与方执行相同配置 uint32_t ringDim 8192; // 环维度越大越安全但越慢 uint32_t scaleModSize 50; // 缩放因子比特大小 uint32_t firstModSize 60; // 第一个模数大小 uint32_t numParties 3; // 参与方数量 CCParamsCryptoContextCKKS parameters; parameters.SetMultiplicativeDepth(1); // 我们只做加法深度为1 parameters.SetScalingModSize(scaleModSize); parameters.SetRingDim(ringDim); parameters.SetFirstModSize(firstModSize); parameters.SetNumParties(numParties); // 关键设置参与方数量 auto cryptoContext GenCryptoContext(parameters); cryptoContext-Enable(PKE); cryptoContext-Enable(KEYSWITCH); cryptoContext-Enable(LEVELEDSHE); cryptoContext-Enable(MULTIPARTY); // 关键启用多密钥功能4.2 分布式密钥生成在单密钥FHE中一方生成密钥对即可。在MK-FHE中密钥生成是一个分布式协议。// 伪代码参与方1Party 0初始化 std::vectorPrivateKey secretKeys(numParties); std::vectorPublicKey publicKeys(numParties); // Party 0 生成自己的第一对密钥 auto keyPair0 cryptoContext-KeyGen(); secretKeys[0] keyPair0.secretKey; publicKeys[0] keyPair0.publicKey; // Party 0 将 publicKeys[0] 广播给其他方 // 伪代码参与方2Party 1加入 // Party 1 收到 publicKeys[0] 后生成自己的密钥对 auto keyPair1 cryptoContext-MultipartyKeyGen(publicKeys[0]); secretKeys[1] keyPair1.secretKey; publicKeys[1] keyPair1.publicKey; // 这是一个“部分公钥” // Party 1 将 publicKeys[1] 广播出去 // 伪代码参与方3Party 2加入并完成联合密钥生成 // Party 2 收到 publicKeys[0], publicKeys[1] 后生成自己的密钥对 auto keyPair2 cryptoContext-MultipartyKeyGen(publicKeys); // 传入已有公钥集合 secretKeys[2] keyPair2.secretKey; publicKeys[2] keyPair2.publicKey; // 现在所有方都有了完整的 publicKeys 数组和各自的 secretKeys[i] // 可以联合生成最终的联合公钥 (Joint Public Key) auto jointPublicKey cryptoContext-MultiKeyJoinPublicKeys(publicKeys); // 每个参与方本地保存 jointPublicKey 和自己的 secretKeys[i]这个过程结束后每个参与方i持有自己的私钥sk_i并且大家都拥有相同的联合公钥jointPK。jointPK将被用于后续的加密。4.3 数据加密与密文上传各方使用联合公钥jointPK加密自己的数据。// 伪代码各方本地加密 // 假设 Party 0 数据为 100.5, Party 1 为 200.3, Party 2 为 150.8 vectordouble dataParty0 {100.5}; vectordouble dataParty1 {200.3}; vectordouble dataParty2 {150.8}; // 各方使用相同的 cryptoContext 和 jointPublicKey 加密 auto ciphertext0 cryptoContext-Encrypt(jointPublicKey, dataParty0); auto ciphertext1 cryptoContext-Encrypt(jointPublicKey, dataParty1); auto ciphertext2 cryptoContext-Encrypt(jointPublicKey, dataParty2); // 各方将 ciphertext_i 上传到计算节点可能是其中一方或第三方服务器这里有一个关键点虽然用了jointPK加密但密文在内部仍然“记得”它主要与哪个参与方的密钥相关。但通过后续的扩展或计算它们能融合。4.4 计算节点执行同态求和计算节点收集到所有密文后直接进行同态加法。在支持MK-FHE的库中如果密文是用正确的联合公钥加密的并且上下文支持多密钥那么同态加法操作会自动处理底层的密钥关联。// 伪代码计算节点执行例如由 Party 0 兼任 auto sumCiphertext cryptoContext-EvalAdd(ciphertext0, ciphertext1); sumCiphertext cryptoContext-EvalAdd(sumCiphertext, ciphertext2); // 现在 sumCiphertext 是一个加密了 (100.5 200.3 150.8) 451.6 的密文 // 但这个密文需要所有方的私钥才能解密。4.5 联合解密计算节点将结果密文sumCiphertext分发给所有参与方。每个参与方进行部分解密。// 伪代码各方进行部分解密 // Party 0 执行 auto partialDecryption0 cryptoContext-MultipartyDecrypt({secretKeys[0]}, sumCiphertext); // Party 1 执行 auto partialDecryption1 cryptoContext-MultipartyDecrypt({secretKeys[1]}, sumCiphertext); // Party 2 执行 auto partialDecryption2 cryptoContext-MultipartyDecrypt({secretKeys[2]}, sumCiphertext); // 各方将 partialDecryption_i 发送给一个指定的聚合方比如 Party 04.6 解密结果聚合聚合方收集所有部分解密份额进行合并最终解密出明文。// 伪代码聚合方Party 0合并解密 vectorCiphertext partials {partialDecryption0, partialDecryption1, partialDecryption2}; vectordouble finalResult; cryptoContext-MultipartyDecryptFusion(partials, finalResult); cout 安全求和结果: finalResult[0] endl; // 应输出 451.6至此一个完整的多密钥安全求和流程就完成了。三方获得了正确的总和但任何一方包括聚合方在整个过程中都无法推算出其他两方的具体输入值假设协议被正确执行且无侧信道攻击。5. 性能瓶颈与优化策略让MK-FHE真正可用MK-FHE的性能问题是其在落地过程中最大的拦路虎。根据我的实测和经验开销主要来自以下几个层面并有相应的优化思路。5.1 密文膨胀与通信开销这是最直观的问题。一个在单密钥下大小为几十KB的密文在10方参与下可能膨胀到几MB甚至几十MB。优化策略参与方数量最小化在业务设计上仔细评估是否真的需要所有方都作为“数据提供方解密方”。有时可以将部分方降级为“纯数据提供方”其数据由某个可信协调方或通过代理重加密用协调方的密钥加密从而减少MK-FHE中的密钥数量。层级化MK-FHE将参与方分组。组内使用MK-FHE进行密集计算组间则通过传统的安全多方计算MPC或可信执行环境TEE进行结果交互。这是一种混合架构思路。压缩与编码在上传密文前使用无损压缩算法如Zstandard对密文序列化后的字节流进行压缩。由于密文数据近似随机压缩比可能不高但网络传输中仍能节省带宽。增量计算与流式处理避免一次性收集所有密文进行计算。设计流式处理框架让密文边产生边计算部分中间结果可以聚合减少单次传输的数据量。5.2 计算开销同态操作尤其是乘法在密文膨胀后复杂度呈非线性增长。优化策略精准参数调优这是FHE应用的通用技能在MK-FHE中更为关键。根据计算深度乘法和加法的次数、参与方数量N、所需精度反复调整ringDim、moduli等参数。目标是找到在安全性和性能之间的最优点。使用库提供的参数自动选择工具如果存在。利用批处理BatchingCKKS和BFV/BGV方案都支持批处理即一个密文可以“打包”成千上万个独立的明文数。在MK-FHE中尽管密文变大了但批处理能力依然存在。确保你的数据向量化一次操作处理大量数据能极大摊薄单次操作的固定开销。GPU加速FHE计算是高度并行化的向量/矩阵运算非常适合GPU。OpenFHE等库正在积极集成CUDA支持。对于计算密集型的MK-FHE应用投资GPU硬件能带来数量级的性能提升。算法级优化重新设计计算逻辑。例如在机器学习中考虑使用更少乘法次数的激活函数如ReLU替代多项式近似或采用低深度模型。5.3 密钥管理与协议复杂度分布式密钥生成和联合解密引入了额外的通信轮次和协议复杂性容易出错且可能成为性能瓶颈。优化策略使用非交互式方案优先选择支持“非交互式密文扩展”的MK-FHE变种。在这种方案中数据方使用联合公钥加密后密文天然就是“可联合计算”的状态无需计算节点进行额外的交互式扩展操作。这简化了流程更适合云服务器计算模型。预计算与缓存联合公钥生成、重线性化密钥等操作可以离线预计算并缓存。在长时间运行的服务中这些密钥材料可以重复使用避免每次计算都重新生成。门限解密采用(t, n)门限解密即n个参与方中任意t个合作即可解密。这提高了系统的可用性和灵活性即使部分方离线也不影响结果获取。但这需要更复杂的分布式密钥生成协议如Joye-Libert门限方案。借助专业框架考虑使用更高层的隐私计算框架如Meta的CrypTen主要面向MPC但理念可借鉴或一些商业隐私计算平台它们可能封装了MK-FHE的复杂性提供了更友好的API和生命周期管理。6. 典型应用场景与架构设计理解了原理和优化手段后我们来看看MK-FHE能在哪些场景中发挥不可替代的作用。它的核心价值在于“数据不动计算动计算可见密文不可见”的跨隐私域协同。6.1 横向联邦学习Horizontal Federated Learning这是MK-FHE的“天作之合”。在横向联邦学习中各参与方拥有相同的特征空间、不同的样本。传统的联邦学习通过交换模型梯度或参数更新来协作训练但仍存在隐私泄露风险如通过梯度反推数据。MK-FHE可以提供更强的安全保障。架构设计初始化所有数据方客户端参与生成MK-FHE的联合公钥jointPK并各自保存私钥。本地加密在每一轮训练中各客户端使用jointPK加密本地计算得到的梯度或模型更新。安全聚合客户端将加密的梯度上传到聚合服务器可能是中心服务器也可能是通过P2P网络。服务器在密文状态下执行聚合操作如加权平均。联合解密聚合服务器将聚合后的加密梯度广播回所有客户端。客户端协作进行联合解密获得聚合后的明文梯度。模型更新各客户端使用解密后的梯度更新本地模型。优势服务器和任何客户端在整个过程中都无法看到其他客户端的原始梯度从根本上防止了从梯度泄露数据。比基于差分隐私或安全聚合协议的方法提供了可证明的、信息论意义上的更强安全保证。6.2 隐私保护的数据联合查询与统计多个机构如银行、运营商希望联合查询黑名单或进行跨域统计如“既在我行有贷款又使用某运营商高端套餐的客户数量”但不愿暴露各自的原始数据列表。架构设计各方将本地数据如用户ID的哈希值或特征值用jointPK加密。查询或统计逻辑被转化为同态电路例如求交集可转化为比较和乘法计数可转化为同态加法。在一个中立的计算节点上执行密文电路计算。各方联合解密获得最终结果如交集数量或统计值。6.3 安全外包计算与隐私云计算用户将敏感数据用用户自己的公钥加密上传到云服务商。后来用户希望授权另一个服务使用不同的密钥对自己的加密数据进行分析。传统FHE需要用户解密后再用新密钥加密。MK-FHE允许云服务商直接在“多密钥密文”上执行计算最终由相关用户联合解密。架构设计这需要云服务商支持动态的“密钥注册”和密文扩展服务。当新用户新密钥加入计算时云服务需要将已有的相关密文进行扩展使其能与新用户的密文一起计算。这对云服务商的FHE运行时提出了更高的要求。7. 常见陷阱、安全考量与实战建议最后分享一些在探索MK-FHE过程中容易踩的“坑”和必须牢记的安全准则。7.1 常见陷阱参数误配导致解密错误或安全漏洞MK-FHE的参数设置比单密钥更敏感。ringDim过小或模数链设计不合理在多方参与和深度计算下噪声会迅速溢出导致解密失败。更危险的是为了能解密而盲目放大参数可能无意中降低了安全等级如LWE问题的难度。务必使用库提供的参数测试工具并在模拟环境中用最大预期参与方数和计算深度进行充分测试。忽略联合解密协议的安全假设联合解密协议本身需要安全信道来传输部分解密份额防止窃听和篡改。同时要防范恶意参与方提交错误的解密份额破坏结果。在实际部署中需要为这部分通信设计认证和验证机制如使用数字签名。混淆“参与方”角色在MK-FHE中“参与方”通常指同时是数据提供方和最终解密方。如果你引入了一个纯计算节点如云服务器它不应该拥有私钥也不应参与解密。清晰定义系统中每个实体的角色并据此设计密钥管理流程。性能预估过于乐观在项目规划阶段一定要做小规模的概念验证PoC获取真实的性能数据密文大小、计算时间、通信量。不要用单密钥FHE的性能数据乘以参与方数来估算MK-FHE的开销往往是指数级或多项式级增长。7.2 安全考量密钥泄露的连锁反应在单密钥FHE中一个密钥泄露只影响该密钥加密的数据。在MK-FHE中一个参与方的长期私钥sk_i泄露攻击者虽然不能直接解密其他方的单独密文但可能危及所有该参与方涉及的历史联合计算结果。需要考虑密钥轮换策略。主动攻击与可验证计算恶意的计算节点可能返回错误的计算结果密文。由于计算发生在密文上参与方难以验证其正确性。需要结合“可验证计算”Verifiable Computation或“零知识证明”技术让计算节点证明其执行了正确的计算。侧信道攻击FHE实现包括MK-FHE同样面临计时攻击、功耗分析等侧信道威胁。确保使用经过安全审计的库如OpenFHE并在可能的情况下在可信执行环境如Intel SGX中运行关键的解密和密钥生成操作。7.3 实战建议从简单场景开始不要一上来就设计几十方参与的复杂机器学习训练。先从2-3方的安全求和、求平均值开始熟悉整个流程、工具链和性能特征。深度依赖社区MK-FHE技术前沿且复杂积极关注OpenFHE、Lattigo等开源库的GitHub仓库、Discord/Slack频道和论文。很多棘手问题的解决方案可能已经由社区讨论或实现。性能监控与 profiling在应用中集成详细的性能指标收集每个阶段的耗时、密文大小、内存占用、网络流量。这些数据是后续优化和容量规划的唯一依据。设计降级与混合方案MK-FHE不是银弹。在实际系统中可以设计一个“安全等级”可调的架构。对于低敏感度、高性能要求的计算可以降级使用传统的MPC或TEE只有对高敏感度的核心计算才启用MK-FHE。这种混合架构更具实用价值。多密钥全同态加密正在从学术论文快步走向工程实践。它带来的“隐私守恒”能力——即数据在联合计算中始终保持加密——对于构建真正可信的分布式数据协作生态至关重要。虽然前方的道路在性能、易用性和标准化方面仍有诸多挑战但作为隐私计算技术栈中一颗璀璨的明珠它的潜力毋庸置疑。对于开发者而言现在正是深入理解、动手实验和探索应用场景的最佳时机。毕竟在数据价值与隐私保护的天平上MK-FHE为我们提供了一个强有力的新砝码。