5. Hybrid Public Key Encryption (混合公钥加密)
5. Hybrid Public Key Encryption (混合公钥加密)
在本节中, 我们定义了几种 HPKE 变体.所有变体都接受一个接收者公钥和一系列明文 pt, 并生成一个封装密钥 enc 和一系列密文 ct.这些输出的构造方式确保只有 skR 的持有者才能从 enc 中解封装密钥并解密密文.所有算法还接受一个 info 参数, 该参数可用于影响密钥的生成 (例如, 用于整合身份信息), 以及一个 aad 参数, 该参数为正在使用的 AEAD 算法提供额外的认证数据.
除了加密到公钥的基本情况外, 我们还包括三种认证变体: 一种认证预共享密钥的持有, 一种认证 KEM 私钥的持有, 以及一种同时认证预共享密钥和 KEM 私钥的持有.所有认证变体都为加密操作贡献额外的密钥材料.以下单字节值将用于区分不同模式:
| Mode (模式) | Value (值) | |============---|========---| | mode_base | 0x00 | | mode_psk | 0x01 | | mode_auth | 0x02 | | mode_auth_psk | 0x03 |
Table 1: HPKE Modes (表1: HPKE 模式)
所有这些情况都遵循相同的基本两步模式:
-
建立发送者和接收者之间共享的加密上下文.
-
使用该上下文来加密或解密内容.
context (上下文) 是一个特定于实现的结构, 它编码了正在使用的 AEAD 算法和密钥, 并管理使用的 nonce, 以确保同一个 nonce 不会与多个明文一起使用.它还具有导出秘密值的接口, 如 5.3节 所述.有关此结构及其接口的描述, 请参见 5.2节.当底层 AEAD 解密失败时, HPKE 解密失败.
这里描述的构造假定相关的非私有参数 (enc, psk_id 等) 由使用 HPKE 的某些应用程序在发送者和接收者之间传输.此外, 拥有多个公钥的接收者需要某种方式来确定其哪个公钥用于封装操作.例如, 应用程序可以将此信息与密文一起从发送者发送到接收者.此类机制的规范留给应用程序.有关更多详细信息, 请参见第 10 节.
请注意, 某些 KEM 可能不支持 AuthEncap() 或 AuthDecap().对于此类 KEM, 仅支持 mode_base 或 mode_psk.定义新 KEM 的未来规范必须指示是否支持这些模式.有关更多详细信息, 请参见 7.1.5 节.
本节中描述的过程以类似 Python 的伪代码列出.使用的算法保持隐式.