4. 密码学工具选型与工程封装

在跨机构联合计算中，密码学工具不是“越强越好”，而是“越匹配越好”。同一份数据，用哈希可以完成一致性校验，却无法支持求和；用同态加密可以支持密文加法，却可能因为密文膨胀和密钥管理成本而不适合高频小查询。选型的核心，是把业务目标翻译成密码学能力需求，再对照各工具的计算开销、通信开销、信任假设和工程封装难度做取舍。

先看能力边界：六类工具能做什么、不能做什么

哈希是单向压缩函数，典型用途是完整性校验、去重标识、承诺绑定和 Merkle 树构造。它不提供机密性，也不支持任何密文计算。工程上要注意：对低熵输入（如手机号、身份证号）直接哈希仍可被字典攻击，必须加盐或使用 HMAC。承诺在哈希基础上增加“隐藏性 + 绑定性”，适合拍卖报价、抽签、联合统计中的“先承诺后揭示”场景。它的性能接近哈希，但需要额外的随机数管理和揭示阶段。

不经意传输（OT）是安全两方计算的基石，发送方有多个消息，接收方只能获取其中一个，而发送方不知道接收方选了哪个。OT 本身不直接完成复杂计算，而是作为混淆电路和秘密分享协议的底层组件。工程中常用 IKNP 类 OT 扩展，把少量“种子 OT”扩展成百万级 OT，通信量从 O(n) 降到 O(κ) 级别。

混淆电路（GC）把函数编译成布尔电路，逐门加密成混淆表，双方通过 OT 传递输入标签，最终由一方解密输出。它适合两方、函数固定、电路规模中等的场景，如隐私求交、比较、集合运算。缺点是电路规模随函数复杂度增长，通信轮数与电路深度相关，且难以支持动态循环和复杂控制流。

秘密分享（SS）把秘密拆成多份分发给不同机构，达到阈值才能重构。它天然支持加法、乘法和比较，适合多方联合统计、联邦求和、门限签名。半诚实模型下性能很好，但恶意模型需要一致性校验，通信开销显著上升。同态加密（HE）允许在密文上直接计算，适合外包计算、密文聚合、隐私保护机器学习推理。它的优势是计算方无需解密，缺点是密文膨胀、乘法深度受限、密钥管理和参数选择复杂。

性能特征：不是单点指标，而是“计算—通信—轮数”三角

工程选型时，最容易被忽略的是通信轮数。哈希和承诺是本地操作，几乎无交互；OT 扩展需要 1～2 轮；混淆电路通常需要常数轮，但通信量与电路规模成正比；秘密分享在多方场景下每做一次乘法就需要一轮交互；同态加密虽然计算方可以离线批量处理，但密文膨胀可达明文的上百倍，网络传输和存储成本不可忽视。

以一个具体示例说明：三家机构要对各自持有的用户年龄做联合求和，样本量各 10 万，年龄为 0～120 的整数。若采用秘密分享，每方把年龄拆成三个份额，两两分发，本地求和后交换一次，再合并得到总和。半诚实模型下，通信量约为 3 × 10 万 × 2 个 64 位整数 ≈ 4.8 MB，延迟在百毫秒级。若改用同态加密，每方加密年龄向量，密文大小约 10 万 × 2 KB = 200 MB，即使只做加法，传输和聚合时间也会上升到秒级甚至更高。若改用混淆电路，需要把加法电路编译成布尔门，10 万次加法对应约 10 万 × 32 位全加器，通信量可能达到数百 MB。这个示例说明：简单聚合优先用秘密分享，而不是默认上 HE 或 GC。

工程封装：把密码学原语变成可调用的服务

实际系统不会让业务方直接调用 OT 或 GC 库，而是封装成统一接口。封装层需要处理四件事：参数协商、密钥/随机数管理、网络传输、结果验证。以秘密分享为例，封装后的接口可以设计为：

// 伪代码：秘密分享聚合服务
interface SSConfig {
  threshold: number;      // 门限 t
  parties: string[];      // 参与方列表
  field: "prime256v1";    // 有限域
}

// 输入：本地向量 localVec
// 输出：聚合结果 aggregate
function secureSum(localVec: number[], cfg: SSConfig): number {
  const shares = splitSecret(localVec, cfg.parties.length, cfg.threshold);
  const partial = shares.map((s, i) => sendTo(cfg.parties[i], s));
  const received = receiveAll(cfg.parties);
  const localSum = sum(received);
  const aggregate = reconstruct(localSum, cfg.threshold);
  return aggregate;
}

封装时要注意：秘密分享的乘法需要 Beaver 三元组预生成，否则每轮都要交互；同态加密的密钥需要由密钥持有方统一管理，计算方只拿公钥和评估密钥；混淆电路的电路文件应预先编译并缓存，避免每次请求都重新生成。对于跨机构场景，还要考虑机构间网络不稳定、时钟不同步、参与方掉线等问题，封装层应提供超时重试和一致性校验。

选型决策表：从业务问题出发

最后，工程封装应提供统一的抽象层，让业务方通过“安全求和”“安全求交”“安全比较”等语义接口调用，而不是直接暴露 OT、GC、HE 的底层参数。封装层内部根据数据规模、参与方数量、信任模型自动选择工具，并记录每次调用的参数、耗时和通信量，便于后续调优和审计。这样，密码学工具才能真正落地为跨机构联合计算的基础设施，而不是停留在论文里的原语。