混合加密

混合加密原语将对称加密的效率与公钥（非对称）加密的便利性结合在一起。任何人都可以使用公钥加密数据，但只有拥有私钥的用户才能解密数据。

对于混合加密，发送者生成一个新的对称密钥来加密每条消息的明文，从而生成密文。该对称密钥与接收方的公钥一起封装。对于混合解密，对称密钥将由接收方进行解封，然后用于解密密文以恢复原始明文。如需详细了解如何存储或传输密文以及密钥封装，请参阅 Tink 混合加密传输格式。

混合加密具有以下属性：

• 保密：除非有权访问私钥，否则任何人都无法获得有关加密明文的任何信息（长度除外）。
• 不对称性：可以使用公钥对密文进行加密，但在解密时，必须使用私钥。
• 随机：加密是随机的。明文相同的两条消息不会产生相同的密文。这样可防止攻击者知道哪个密文与给定的明文对应。

混合加密在 Tink 中表示为一对基元：

• 使用 HybridEncrypt 进行加密
• HybridDecrypt 进行解密

上下文信息参数

除了明文之外，混合加密还接受一个额外参数 context_info，该参数通常是从上下文隐式的公开数据，但应该绑定到生成的密文。这意味着密文允许您确认上下文信息的完整性，但不保证其机密性或真实性。实际的上下文信息可以为空或 null，但为了确保能够正确解密生成的密文，必须提供相同的上下文信息值进行解密。

混合加密的具体实现可以通过各种方式将上下文信息绑定到密文，例如：

• 使用 context_info 作为 AEAD 对称加密的关联数据输入（请参阅 RFC 5116）。
• 使用 context_info 作为 HKDF 的“CtxInfo”输入（如果实现使用 HKDF 作为密钥派生函数，请参阅 RFC 5869）。

选择密钥类型

对于大多数使用场景，我们建议使用 DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM 密钥类型。此密钥类型实现了 RFC 9180 中指定的混合公钥加密 (HPKE) 标准。HPKE 由密钥封装机制 (KEM)、密钥派生函数 (KDF) 和基于关联数据的经身份验证加密 (AEAD) 算法组成。

DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM具体采用以下员工：

• KEM：使用 HKDF-SHA-256 通过 Diffie–Hellman 通过 Curve25519 推导共享密钥。
• KDF：HKDF-SHA-256，用于推导发送者和接收者上下文。
• AEAD：采用 HPKE 标准生成的 AES-256-GCM，包含 12 字节的 Nonce。

其他受支持的 HPKE 密钥类型包括但不限于：

• DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
• DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_CHACHA20_POLY1305
• DHKEM_P256_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
• DHKEM_P521_HKDF_SHA512_HKDF_SHA512_AES_256_GCM

如需详细了解 KEM、KDF 和 AEAD 的算法选择，请参阅 RFC 9180。

如 Victor Shoup 的 ISO 18033-2 标准中所述，虽然已不再推荐使用，但 Tink 还支持 ECIES 的某些变体。下面列出了一些受支持的 ECIES 密钥类型：

• ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM
• ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM
• ECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256
• ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256

基本属性

注意 ：混合加密仅提供隐私性，无法提供真实性。只有接收者可以接受匿名消息或依赖其他机制对发送者进行身份验证时，才算安全。

• 明文和上下文信息可以具有任意长度（在 0..2³² 字节范围内）
• 防范自适应选择的密文攻击
• 针对基于椭圆曲线的方案的 128 位安全性

用例示例

请参阅“我要交换数据”。