混合加密

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

对于混合加密，发送者生成一个新的对称密钥来加密每条消息的明文，从而生成密文。该对称密钥与接收方的公钥一起封装。对于混合解密，对称密钥将由接收方进行解封，然后用于解密密文以恢复原始明文。如需详细了解如何存储或传输密文以及密钥封装，请参阅 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..232 字节范围内）
  • 防范自适应选择的密文攻击
  • 针对基于椭圆曲线的方案的 128 位安全性

用例示例

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