混合加密原语将对称加密的效率与公钥（非对称）加密的便利性结合在一起。任何人都可以使用公钥加密数据，但只有拥有私钥的用户才能解密数据。
对于混合加密，发送者生成一个新的对称密钥来加密每条消息的明文，从而生成密文。该对称密钥与接收方的公钥一起封装。对于混合解密，对称密钥将由接收方进行解封，然后用于解密密文以恢复原始明文。如需详细了解如何存储或传输密文以及密钥封装，请参阅 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_GCMDHKEM_X25519_HKDF_SHA256_HKDF_SHA256_CHACHA20_POLY1305DHKEM_P256_HKDF_SHA256_HKDF_SHA256_AES_128_GCMDHKEM_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_GCMECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCMECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256
基本属性
- 明文和上下文信息可以具有任意长度（在 0..232 字节范围内）
- 防范自适应选择的密文攻击
- 针对基于椭圆曲线的方案的 128 位安全性
用例示例
请参阅“我要交换数据”。