跳到主要内容

9.1.2. Computational Analysis (计算分析)

9.1.2. 计算分析​

[CS01] 中显示, 与此处描述的 Base 模式本质上相同形式的混合公钥加密方案在底层 KEM 和 AEAD 方案是 IND-CCA2 安全的情况下是 IND-CCA2 安全的。此外, [HHK06] 中显示, KEM 和数据封装机制的 IND-CCA2 安全性是实现混合公钥加密的 IND-CCA2 安全性的必要条件。[CS01] 中提出的方案与本文档中的 Base 模式 (都命名为 HPKE) 之间的主要区别在于我们在 KEM 和 AEAD 之间插入了一些 KDF 调用。因此, 分析本文档中的 HPKE Base 模式实例化需要验证额外的 KDF 调用不会导致 IND-CCA2 属性失效, 以及验证额外的导出密钥保密性属性。

分析本文档中定义的 PSK、Auth 和 AuthPSK 模式还需要验证发送方认证属性。虽然 PSK 模式只是向密钥调度添加补充密钥材料, 但 Auth 和 AuthPSK 模式使用非标准的认证 KEM 构造。通常, HPKE 的认证模式可以被视为并分析为签密的各种变体 [SigncryptionDZ10]。

[HPKEAnalysis] 中对所有 HPKE 模式进行了初步的计算分析, 表明在 KEM 是 DHKEM、AEAD 是任何 IND-CPA 安全和 INT-CTXT 安全方案, 以及 DH 组和 KDF 满足以下条件的情况下具有渐近安全性:

  • DH 组: 间隙 Diffie-Hellman (GDH) 问题在适当的子群中是困难的 [GAP]。

  • Extract() 和 Expand(): Extract() 可以建模为随机预言机。Expand() 可以建模为伪随机函数, 其中第一个参数是密钥。

特别是, 本文档中定义的 KDF 和 DH 组 (参见第 7.2 节和第 7.1 节) 在按指定使用时满足这些属性。[HPKEAnalysis] 中的分析表明, 在这些约束下, HPKE 继续提供 IND-CCA2 安全性, 并提供上述额外属性。此外, 该分析确认在上述不同的密钥泄露情况下预期的属性成立。该分析考虑了发送方使用加密上下文发送一条消息, 并另外使用秘密导出接口导出两个独立的秘密。

下表总结了 [HPKEAnalysis] 的主要结果。N/A 表示属性不适用于给定模式, 而 Y 表示给定模式满足该属性。

变体消息保密性导出保密性发送方认证
BaseYYN/A
PSKYYY
AuthYYY
AuthPSKYYY

表 6: HPKE 模式安全属性

如果要将非基于 DH 的 KEM 与 HPKE 一起使用, 将需要进一步分析来证明其安全性。[CS01] 的结果提供了一些迹象表明任何 IND-CCA2 安全的 KEM 在这里都足够, 但考虑到方案的差异, 结论并不确定。

[ABHKLR20] 中对 HPKE 的 Auth 模式单次加密 API 进行了详细的计算分析。该论文使用签密 [SigncryptionDZ10] 中已知的外部者和内部者安全术语为认证 KEM 和认证公钥加密定义了安全概念。该分析证明 DHKEM 的 AuthEncap()/AuthDecap() 接口对本文档中指定的所有 Diffie-Hellman 组满足这些概念。该分析还提供了精确的安全界限, 假设间隙 Diffie-Hellman (GDH) 问题在适当的子群中是困难的 [GAP], 并且 HKDF 可以建模为随机预言机。

此外, [ABHKLR20] 证明了组合定理, 表明 HPKE 的 Auth 模式对本文档中指定的所有 KDF 和 AEAD 方案满足认证公钥加密的安全概念, 前提是任何认证 KEM 满足先前定义的认证 KEM 的安全概念。这些定理假设 KEM 是完全正确的; 它们可以很容易地适应于具有非零但可忽略的解密失败概率的 KEM。对 KDF 的假设是 Extract() 和 Expand() 可以分别建模为伪随机函数, 其中第一个参数是密钥。对 AEAD 的假设是 IND-CPA 和 IND-CTXT 安全性。

总之, [ABHKLR20] 中的分析证明 HPKE 的 Auth 模式的单次加密 API 满足本节开头列出的所需消息机密性和发送方认证属性; 它不考虑多条消息, 也不考虑秘密导出 API。

最后于 更新