想象一台正在进行中的急诊手术。主刀医生面前躺着一位危重患者,体内藏着需要切除的病灶——这就是我们要保护的数据。按理说,医生应该直接下刀精准操作。但手术室的铁律是:任何人都不能“看见”病灶的真实模样,否则会严重灼伤患者的隐私。于是,医生被迫戴上一双极厚的隔热手套,在这双笨重手套的束缚下完成所有精密操作。 这双隔热手套,就是“同态加密”。它允许医生在不摘手套(不解密)的情况下,隔着手套完成切割与缝合——也就是直接对加密数据做计算,结果解密后与直接手术完全一致。代价也显而易见:手套太厚,手指失去触感,每个动作都要多花成百上千倍的力气;手套还会被手术中的污渍不断糊住(这就是“噪声”),用久了必须更换一副新手套(这就是“自举”),而换手套本身也是一台极其昂贵的小手术。 好消息是,这些年医生们练出了一套“厚手套手术技艺”:改进缝合手法(算法优化)、换上电动工具(硬件加速)、学会一次缝合多根线(SIMD 打包)、科学安排换手套的时机(自举优化)。本文就从这间手术室出发,把同态加密性能优化的完整策略讲给你听。

岗位关联

对 AI 从业者而言,掌握同态加密的性能优化是隐私计算从“能跑 Demo”迈向“能上生产”的分水岭,直接决定你在医疗、金融等高敏感场景中能否把技术落地为真实商业价值。

目录
  1. 可视化演示
  2. 性能瓶颈分析
  3. 算法级优化
  4. 硬件加速
  5. 自举优化
  6. 工程实践
  7. 典型应用
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

对比BFV/BGV/CKKS三种同态加密方案的加密、解密、同态运算耗时,展示批量化、重线性化、模数切换等优化策略的加速效果。

本节配有交互动效(进入视口后自动加载,约 3KB)。

同态加密方案性能对比 对比BFV、BGV、CKKS三种方案的加密、解密、同态运算耗时 T_total = T_enc + T_eval + T_dec 拖动滑块调节多项式度数观察性能变化

性能瓶颈分析

医生戴上了隔热手套,第一感受是什么?笨。原本灵巧的手指如今像绑了十块海绵,拿针要摸半天,缝线要反复对准。更糟糕的是,这双手套比手大好几圈——你明明只想切一个 1 厘米的小口子,手套却要占据 100 倍的体积。换成同态加密的视角:原始数据只有几个字节,加密后却变成几百 KB 的多项式,这就是“密文膨胀”。

手术持续进行,另一个麻烦也冒了出来:手套上不断沾染组织液和纤维碎屑,越积越厚,最后厚到完全失去触感。对应到同态加密,每一次乘法运算都会让“噪声”爆炸式增长,噪声一旦超过安全上限,解密出来的结果就是一团乱码。更糟的是,密钥也不省心——为了支撑密集运算,公钥里塞满了多项式,像腰间挂着一大串沉甸甸的钥匙,走到哪都拖累速度。

这三座大山——密文膨胀、噪声累积、密钥与计算开销,构成了同态加密性能瓶颈的全部根源。性能优化的本质,就是在这三座大山之间开隧道、架桥梁。

回到手术室:密文膨胀决定了医生的“手套体积”,噪声决定了“手套能用多久”,密钥规模决定了“腰间钥匙串有多重”。弄懂了这三件事,你就能理解为什么同态加密比明文计算慢几个数量级——也能明白后续所有优化策略都是在跟这三座大山博弈。

膨胀率=∣ct∣∣pt∣\text{膨胀率} = \frac{|\mathrm{ct}|}{|\mathrm{pt}|}
这组公式是说:把明文体积和密文体积放在一个分数里比一比,商就是数据膨胀了多少倍。
  1. 明文体积原始数据的存储大小,比如一个 32 位整数只占 4 字节
    ∣pt∣|\mathrm{pt}|
  2. 密文体积加密后包含多个多项式的大对象,通常有几十万字节
    ∣ct∣|\mathrm{ct}|
  3. 膨胀率两者相除得到倍数,实际方案中常达到数百甚至上千倍
    ∣ct∣∣pt∣≈102∼103\frac{|\mathrm{ct}|}{|\mathrm{pt}|} \approx 10^2 \sim 10^3

算法级优化

既然手套这么笨,能不能改变手术手法本身?当然能。优秀的医生会练就“一把针缝多根线”的绝活——一次落针,同时穿过四根缝合线,效率翻四倍。在密码学里,这叫 SIMD 打包:把一个明文向量塞进同一个密文的多个“槽位”里,一次同态运算,就能同时处理 n 份数据。

批处理则是把多个患者的手术合并到同一台手术里。医院不再为一个病人开一台机器,而是把几十个病人的数据整齐排进一张大表格,一次性完成计算。配合参数调优,医生可以挑选更趁手的手套厚度:模数选得大,噪声预算足,能多算几轮;但模数太大,手套也更厚,速度更慢——这中间要反复权衡。

有时手术动作太花哨(比如非线性运算),医生会先把它拆解成标准化的基础动作。这就是多项式近似:把 sigmoid、ReLU 这类函数用泰勒多项式逼近,把昂贵的复杂运算变成同态加密擅长的加法和乘法。

手术手法升级后,效率肉眼可见地提升:同一台手术,以前一次只处理一个数据点,现在一次处理一整排。而接下来要做的,是把这套手法从“手艺”变成“科技”——引入更强大的工具。

Enc(m1,…,mn)⊙Enc(m1′,…,mn′)=Enc(m1m1′,…,mnmn′)\mathrm{Enc}(m_1, \dots, m_n) \odot \mathrm{Enc}(m'_1, \dots, m'_n) = \mathrm{Enc}(m_1 m'_1, \dots, m_n m'_n)
这条公式说明 SIMD 打包的本质:两个密文各自装着 n 个数据,一次同态乘法后,每个对应槽位各自算好自己的乘法,互不干扰。
  1. 明文槽编码把 n 个数据装入一条明文的 n 个槽位,像把 n 根线穿进同一根针
    Enc(m1,m2,…,mn)\mathrm{Enc}(m_1, m_2, \dots, m_n)
  2. 同态运算两个密文执行一次乘法,每个槽位逐项对应相乘
    ⊙Enc(m1′,m2′,…,mn′)\odot \mathrm{Enc}(m'_1, m'_2, \dots, m'_n)
  3. 一次等于 n 次右侧得到 n 个密文结果,吞吐量近似提升 n 倍
    =Enc(m1m1′,m2m2′,…,mnmn′)= \mathrm{Enc}(m_1 m'_1, m_2 m'_2, \dots, m_n m'_n)

硬件加速

再精湛的手法也敌不过趁手的工具。医生如果换上一台电动缝合器,原本需要抖动手腕十分钟的动作,现在一按开关就完成了。在同态加密的世界里,GPU 就是这台电动缝合器:数千个计算核心同时开工,把密文多项式里海量的模乘和 NTT(数论变换)运算拆成无数并行任务,吞吐量瞬间提升几十上百倍。

FPGA 则更“定制化”——它像为这位医生量身定做的机械臂,把多项式乘法流水线直接烧录进芯片,牺牲灵活性换来极致的吞吐与能效。而 CPU 上的 AVX-512 指令则像一把更锋利的剪刀,让每条指令同时处理 512 位的数据,把模乘运算的底层效率再拔高一截。

但工具再好,也要有人把器械台摆得井井有条。内存优化关注的就是这个:密文对象动辄几 MB,频繁分配释放会拖垮性能。把数据布局改成连续存储,让 CPU/GPU 的缓存命中率提高,访存时间大幅缩短——这也是硬件加速中常被忽略的一环。

电动工具虽好,但并不能解决所有问题。GPU 再快,也绕不过“手套快脏了必须换”的现实——这就轮到自举登场了。

S=1(1−p)+pNS = \frac{1}{(1-p) + \frac{p}{N}}
阿姆达尔定律告诉我们:并行加速不是无限的,能被并行化的部分占比 p 决定了加速比的上限。
  1. 可并行比例任务中能同时拆分给多个计算单元的比例,p 越接近 1 越好
    pp
  2. 并行单元数N 代表并行处理的单元个数,如 GPU 核心组数或线程数
    NN
  3. 加速比上限当 N 趋向无穷大,加速比收敛到 1/(1-p),串行部分是天花板
    lim⁡N→∞S=11−p\lim_{N \to \infty} S = \frac{1}{1-p}

自举优化

手术时间一长,隔热手套上糊满污渍,医生已经摸不出针脚的位置。这时唯一的选择是:摘下旧手套,换上一副全新的。可同态加密有个奇特的限制——你绝不能“摘手套”(解密)。那怎么办?天才的答案是:戴着旧手套,再套一层新手套,在两层手套之间完成“换手套”的动作。

这就是自举(Bootstrapping):把当前的密文和私钥都加密一遍,再在同态状态下执行一次解密运算。解密动作清除了旧密文里积累的绝大多数噪声,输出的新密文像刚出厂一样干净,于是计算链可以继续延长。不过代价也很昂贵——一次自举的计算量,可能比之前所有运算加起来还大。

为此,医生练出了“稀疏自举”的技巧:只刷新噪声最严重的那部分槽位,而不是整副手套都换。再配合层级调度,事先规划好整台手术要换几次手套、分别在什么节点换,避免中途意外“失手”。噪声预算管理则像手术前的风险评估,提前算好每一步会蹭上多少污渍,确保每一副手套都物尽其用。

自举是手术室里最贵却也最关键的耗材。怎么把钱花在刀刃上?答案是流程管理——这引出了工程实践的智慧。

Recrypt(c)=Dec(Enc(sk),Enc(c))\mathrm{Recrypt}(c) = \mathrm{Dec}\big(\mathrm{Enc}(sk), \mathrm{Enc}(c)\big)
自举公式的核心:把私钥和密文都加密,然后在加密状态下解密一次,得到噪声被刷新的新密文。
  1. 加密私钥先把私钥加密成“私钥的影子”,安全地交给计算方
    Enc(sk)\mathrm{Enc}(sk)
  2. 加密密文把当前密文当作普通数据再加密一次,套上第二层箱子
    Enc(c)\mathrm{Enc}(c)
  3. 同态解密用私钥的影子,在双层加密状态下执行解密,噪声被压缩回初始水平
    Dec(Enc(sk),Enc(c))\mathrm{Dec}\big(\mathrm{Enc}(sk), \mathrm{Enc}(c)\big)

工程实践

一间高效的手术室,靠的不是某个医生单打独斗,而是整套流程的默契。选对设备品牌是第一件事:同态加密领域有 OpenFHE、Microsoft SEAL、HElib 等成熟“器械商”,它们在性能、易用性、支持深度上各有千秋。生产环境选型时,要像医院招标一样,用真实业务流量做基准测试,而不是看论文里的理想数字。

手术室里的第二件事是排班:多线程并行让多个手术台同时运转,把大任务切碎后分配给不同护士团队分头处理。第三件事是器械复用:同态加密里频繁创建密文对象极其昂贵,用内存池复用缓冲,能像循环消毒使用手术钳一样,把内存分配的次数降到最低。第四件事是缓存策略:NTT 的旋转因子表、密钥切换的预计算表,这些“常用器械”永远放在手边,免得每次都用时现造。

四个环节环环相扣:库选型定基调,线程并行提吞吐,内存复用降开销,缓存策略省时间。它们是让前面所有算法优化真正落地的“最后一百米”。

流程理顺了,手术室就能正式接待“多科室会诊”了。这些优化最终要服务于真实世界的复杂场景。

Tp=Tsp+ToverheadT_p = \frac{T_s}{p} + T_{\text{overhead}}
并行总耗时等于串行部分除以并行度 p,再加上线程通信与同步的额外开销——工程优化的本质就是压缩这两项。
  1. 串行时间单线程完整执行一遍任务所需的总时间
    TsT_s
  2. 并行分摊可并行部分被 p 个线程平分,耗时变成串行时间的 1/p
    Tsp\frac{T_s}{p}
  3. 额外开销线程切换、同步等待、数据通信带来的附加成本,不可忽略
    ToverheadT_{\text{overhead}}

典型应用

现在,来自三家医院的专家要对同一位疑难患者会诊,但谁都不愿意亮出自己的完整病历。于是每个人都戴着手套,把病历加密后扔进公共区域,专家们在密文状态下讨论、比较、计算。这就是同态加密最典型的应用场景:多方在完全不泄露原始数据的前提下,完成联合计算。

隐私求交(PSI)是第一个落地点:两家银行想找出共同的欺诈客户名单,但都不希望对方知道自己的完整客户列表。同态加密让双方在密文上求交集,结果只有共同部分可见。联邦学习是第二个主战场:各参与方本地训练模型,只上传加密的梯度,服务器在同态状态下完成聚合更新,模型学得会,但谁也偷不走原始梯度。

密文查询则让云数据库变得“可信”——用户把数据加密后存在云端,查询时云服务器直接在密文上执行检索和聚合,用户拿回结果解密即可,云厂商即使被拖库也看不到任何明文。医疗场景更是价值连城:多家医院联合训练癌症早筛模型,基因数据、影像数据全部以密文参与计算,患者的隐私被守护得严严实实。

从手术室到会诊室,从单点突破到多方协作,同态加密性能优化这整套“厚手套手术学”,终于在你面前完整铺开。

⨁i=1nEnc(xi)=Enc(∑i=1nxi)\bigoplus_{i=1}^{n} \mathrm{Enc}(x_i) = \mathrm{Enc}\Big(\sum_{i=1}^{n} x_i\Big)
这条聚合公式说明:n 个参与方各自加密自己的数据,密文直接相加后解密,得到总和,但单个数据从未暴露。
  1. 逐项加密每个参与方用同态公钥加密自己的数据,保护本地隐私
    Enc(x1),Enc(x2),…,Enc(xn)\mathrm{Enc}(x_1), \mathrm{Enc}(x_2), \dots, \mathrm{Enc}(x_n)
  2. 同态累加密文之间直接做加法运算,不需要解密任何一方数据
    ⨁i=1nEnc(xi)\bigoplus_{i=1}^{n} \mathrm{Enc}(x_i)
  3. 聚合解密最终解密只得到总和,任何一方的原始值都无法被还原
    Enc(∑i=1nxi)\mathrm{Enc}\Big(\sum_{i=1}^{n} x_i\Big)

AI 应用场景

医疗影像联邦学习

阶段:模型训练与隐私保护

解决的问题:传统方式下,医院间共享医疗数据受法律与隐私严格限制,数据孤岛导致 AI 模型训练数据不足。同态加密让各医院上传加密后的梯度,聚合服务器在密文上完成联邦平均,模型照常收敛,但任何患者的原始影像和诊断数据都不出本院。

具体案例:某肿瘤研究中心联合 5 家三甲医院,使用基于 CKKS 方案的同态加密库对 10 万张肺部 CT 进行联邦训练。通过 SIMD 打包和 GPU 加速,每轮聚合耗时从 40 分钟压到 6 分钟,模型 AUC 达到 0.91,与明文训练的 0.93 几乎持平。

金融反欺诈隐私求交

阶段:数据预处理与特征工程

解决的问题:多家银行各自掌握一部分欺诈特征,但受监管约束不能直接交换客户名单。传统 PSI 依赖可信第三方,存在单点泄露风险。基于同态加密的隐私求交让银行在密文上计算交集,只获取共同欺诈客户的加密特征。

具体案例:某支付平台与 3 家银行做黑名单 PSI,原始数据各 5000 万条,通过批处理技术将 4 字节整数按 8192 个槽位打包,配合多线程并行,完整求交从 2.5 小时缩短至 14 分钟,拦截率提升 18%。

云上密文数据仓库

阶段:数据存储与服务调用

解决的问题:企业把核心业务数据存放在公有云上,虽然省心但担心云厂商窥探数据。传统方案是先解密再查询,隐私与效率不可兼得。同态加密支持在密文上直接执行筛选、聚合、统计查询。

具体案例:某电商 SaaS 服务商将用户行为日志以同态加密形式存入云数仓,通过自定义多项式近似实现加密状态下的均值、方差和 Top-K 统计,查询延迟从明文 200ms 上升到 5 秒,但保证云厂商即使拿到数据库备份也无法还原任何用户记录。

Python 演示

python64 行
import timeimport random  class PlainOps:    """明文基线计算:直接、快速、无噪声。"""     @staticmethod    def compute(data):        return [x * 2 + 1 for x in data]  class HomomorphicOpsSim:    """模拟同态加密计算:极慢的逐元素运算 + 噪声累积与自举。"""     NOISE_LIMIT = 50     def __init__(self, batch_size=1):        self.batch_size = batch_size        self.noise = 0        self.boot_count = 0     def compute(self, data):        result = []        t0 = time.time()        for i in range(0, len(data), self.batch_size):            chunk = data[i:i + self.batch_size]            for x in chunk:                # 模拟同态乘法内部的大整数多项式运算                for _ in range(2000):                    _ = (x * x + x) % 10007                result.append((x * 2 + 1) % 10007)            # 每批数据都会引入噪声            self.noise += self.batch_size * random.randint(1, 3)            if self.noise > self.NOISE_LIMIT:                # 模拟自举:花费时间并重置噪声                time.sleep(0.02)                self.noise = 5                self.boot_count += 1        elapsed = time.time() - t0        return result, elapsed  def compare(data_size=200, batch_size=8):    data = list(range(data_size))     t0 = time.time()    plain_res = PlainOps.compute(data)    plain_time = time.time() - t0     he = HomomorphicOpsSim(batch_size=batch_size)    he_res, he_time = he.compute(data)     ratio = he_time / max(plain_time, 1e-6)    print(f"数据规模: {data_size}")    print(f"明文计算耗时: {plain_time:.4f} 秒")    print(f"模拟同态计算耗时: {he_time:.4f} 秒")    print(f"性能差距: {ratio:.1f} 倍")    print(f"模拟自举次数: {he.boot_count}")    print(f"结果一致性验证: {plain_res == he_res}")  if __name__ == "__main__":    compare(data_size=200, batch_size=8)
目的:用纯 Python 模拟同态加密与明文计算的性能差异,并演示批处理与噪声自举的基本机制。
  1. class HomomorphicOpsSim模拟同态加密的“笨重手套”,每次运算都要执行额外的大整数多项式循环
  2. for _ in range(2000):模拟同态乘法比明文乘法高出三个数量级的计算开销
  3. self.noise += self.batch_size * random.randint(1, 3)每处理一批数据,噪声按数据量累积
  4. if self.noise > self.NOISE_LIMIT:噪声超过阈值触发自举,清空噪声并增加耗时
  5. time.sleep(0.02)模拟自举刷新噪声时消耗的额外时间成本
  6. ratio = he_time / max(plain_time, 1e-6)计算性能差距,避免明文耗时为零时除零错误

常见误区

误区我刚开始学同态加密时,以为它是个“加密计算器”——把数据放进去,不管算多少步,按等号出来的结果总是对的。教程里的例子也都是一两步运算,看起来毫无问题。

正解每次运算都会给“手套”蹭上噪声,尤其是乘法,会让噪声像滚雪球一样爆炸式增长。噪声一旦超过模数上限,解密结果就是乱码。性能优化的所有手段——参数调优、自举、层级调度——本质上都是在跟噪声上限赛跑。正确做法是先用噪声预算估算工具算好能跑几层乘法,再设计计算电路。

为何常见:入门教程只演示小参数、浅层电路,噪声远未触及上限,让人误以为计算是无代价的。

误区既然自举能把噪声归零,那我每做一次乘法就自举一次,不就可以无限计算任意复杂度的函数了吗?听起来完美!

正解自举的“换手套”手术本身极其昂贵,一次自举的耗时可能超过之前所有运算的总和。频繁自举的代价不是线性增长,而是灾难性放大。工程上要追求“少换、换对”:用噪声预算管理精确预测何时到达上限,只在临界点做稀疏自举,再配合层级调度整体规划。

为何常见:大家只看到自举“能”清理噪声,没算清它的成本;GPU 加速自举后更快,更掩盖了它的相对开销。

误区听说 SIMD 打包能一次处理 n 份数据,我立刻把所有计算都往槽位里塞,结果发现根本跑不起来——有的槽位结果错了,有的数据对不齐,速度也没提升多少。

正解SIMD 需要满足两个前提:一是数据必须对齐到固定槽位,不同槽位的运算是相互独立的,不能跨槽位通信;二是所有槽位执行的是同一条指令,任务必须是“同构”的。如果计算流程里有分支、有数据依赖,强行打包只会浪费槽位。此外,打包后密文尺寸变大,噪声预算也要重新核算,要综合评估收益。

为何常见:Demo 里打包后速度提升极其亮眼,让人忽略了数据结构与计算模式必须匹配的约束。

误区厂商宣传 GPU 加速能让同态加密快 100 倍,那几百倍差距应该就抹平了吧?以后生产环境可以直接无脑上同态加密了。

正解GPU 等硬件加速确实能把吞吐量提升一到两个数量级,但同态加密与明文之间的性能鸿沟通常是三个数量级起步——这还没算上密文传输、密钥切换和自举的开销。硬件加速不是终点,而是要跟算法优化、批量处理、工程调优组合使用,才能把差距缩小到业务可接受的范围。

为何常见:宣传材料倾向于突出“加速倍数”而不是绝对耗时,拿掉“相比明文慢多少倍”的参照系,误导了技术选型。

误区我刚开始做项目时,随手捡了一个库就开始写代码,觉得反正都是同态加密,底层应该大差不差。结果性能差得离谱,迭代了好几版才发现是选错了库。

正解不同库的底层方案差异巨大:Microsoft SEAL 主打 BFV/CKKS 且 API 精致;HElib 以 BGV 为主,自举实现成熟;OpenFHE 开源生态好,支持多种方案和硬件后端;Palisade 在网关场景口碑好。选型必须结合业务的数据类型(整数还是浮点)、电路深度(需要几层乘法)、部署环境(CPU/GPU/FPGA)做基准测试,而不是看 Star 数。

为何常见:初学者容易把“同态加密”当成一个黑盒统一接口,忽略了不同实现背后的安全参数、噪声增长模型和优化深度完全不同。

面试题

Q1. 关于密文膨胀,以下说法正确的是?

单选题 · easy

  • A.密文比明文大得多← 正确答案
  • B.明文比密文大得多
  • C.两者体积基本相同
  • D.密文一定更小更快

答案:A。同态加密中密文通常包含多个多项式,体积比明文大数百到上千倍。就像医生戴的隔热手套比手大好几圈,体积膨胀直接导致存储和传输开销剧增。其他选项描述的“明文更大”“体积相同”“密文更快”都与实际相反。

Q2. 同态计算中噪声不断累积,最终会导致?

单选题 · easy

  • A.发生密钥自动更换
  • B.解密失败结果错误← 正确答案
  • C.密文体积迅速变小
  • D.计算速度反而变快

答案:B。噪声像手术手套上越积越厚的污渍,超过模数上限时,解密得到的明文会完全错乱。A 的密钥自动更换不存在,C 与密文膨胀矛盾,D 中噪声不影响速度,只会破坏正确性。

Q3. 同态加密的典型应用场景有哪些?

单选题 · easy

  • A.联邦学习安全聚合← 正确答案
  • B.网络爬虫数据抓取
  • C.图像风格迁移生成
  • D.文本情感极性分析

答案:A。联邦学习需要在不泄露参与者原始数据的前提下聚合模型梯度,是同态加密的标志性场景。B、C、D 分别属于爬虫、CV 生成和 NLP 分类任务,不涉及多方隐私保护计算,不需要同态加密。

Q4. SIMD 打包技术的主要思想是?

单选题 · mid

  • A.减少移动设备内存
  • B.一条指令处理多条数据← 正确答案
  • C.用磁盘代替内存存储
  • D.把密文拆成多个小块

答案:B。SIMD 打包把多个明文数据装入同一个密文的不同槽位,一次同态运算同时处理所有槽位,像一根针同时缝合多根线。A、C 是关于存储的无关描述,D 反了——SIMD 是合并而非拆分密文。

Q5. 自举(Bootstrapping)的核心作用是?

单选题 · mid

  • A.压缩密文减少体积
  • B.刷新噪声维持计算← 正确答案
  • C.更换密钥提升安全
  • D.把密文转换成明文

答案:B。自举通过在加密状态下执行解密,把靠近噪声上限的旧密文替换成噪声重置的新密文,让计算链得以延续。A 是密文压缩的目标,C 与安全性无关,D 是解密操作,会暴露明文,与自举完全相反。

Q6. 下列哪项最适合做同态加密硬件加速?

单选题 · mid

  • A.普通机械硬盘
  • B.GPU 并行计算卡← 正确答案
  • C.旧款单核小芯片
  • D.低速以太网线缆

答案:B。同态加密的核心运算是大整数多项式乘法与 NTT,GPU 拥有数千个并行核心,极其适合这类高吞吐计算。硬盘和网线是存储/网络设备,单核芯片并行度太低,都不适合做计算加速。

Q7. 关于噪声与噪声预算,以下哪项理解正确?

单选题 · mid

  • A.噪声只影响速度不影响正确性
  • B.噪声预算用完前必须自举← 正确答案
  • C.加法比乘法产生更多噪声
  • D.噪声越大密文体积越小

答案:B。噪声预算是噪声到达解密上限前的“余量”,一旦耗尽就会解密失败,因此必须在耗尽前通过自举刷新。A 错在噪声直接破坏正确性;C 错,乘法噪声远大于加法;D 与密文膨胀矛盾。

Q8. 下列哪些属于算法级性能优化手段?

多选题 · mid

  • A.使用 SIMD 打包编码← 正确答案
  • B.把多组数据批量装入← 正确答案
  • C.调整安全参数降低噪声← 正确答案
  • D.更换光模块提升带宽

答案:ABC。SIMD 打包(A)让一次运算处理多份数据,批处理(B)把多组数据合并成一批,参数调优(C)在安全性不变前提下选择更高效的模数。D 属于网络硬件的范畴,与算法级优化无关。

Q9. 自举刷新噪声的主要代价是什么?

单选题 · hard

  • A.计算开销极大速度慢← 正确答案
  • B.会直接降低安全强度
  • C.让解密密钥完全公开
  • D.导致密文无法再计算

答案:A。自举需要把整个解密电路在加密状态下执行,涉及大量模乘和密钥切换,一次自举的耗时可能比之前所有计算加起来还多,所以工程上要尽量减少自举次数。B、C、D 都与自举的真实代价无关。

Q10. 同态加密工程实践中降低开销的手段有哪些?

多选题 · hard

  • A.复用内存缓冲避免分配← 正确答案
  • B.预计算 NTT 查表缓存← 正确答案
  • C.多线程并行处理任务← 正确答案
  • D.使用更短的密钥长度

答案:ABC。内存复用(A)减少密文频繁创建的开销,NTT 预计算(B)让常用旋转因子表随取随用,多线程并行(C)把大任务拆到多核执行。D 缩短密钥长度会直接削弱安全性,属错误做法。

Q11. 设某同态计算任务可并行比例为 0.75,双核并行(N=2),根据阿姆达尔定律加速比约为?

单选题 · extreme

  • A.1.6 倍← 正确答案
  • B.2.0 倍
  • C.2.5 倍
  • D.3.2 倍

答案:A。代入公式 S=1/((1-0.75)+0.75/2)=1/(0.25+0.375)=1/0.625=1.6。即使两核全开,加速比也只有 1.6 倍,因为 25% 的串行部分成了天花板。这正是工程实践中要同时优化串行瓶颈与并行效率的原因。