Hybrid encryption

Hybrid Encryption combines the efficiency of symmetric encryption with the convenience of public-key (asymmetric) encryption. Only users with the private key can decrypt the data.

To encrypt a message, a fresh symmetric key is generated and used to encrypt the plaintext data. The recipient’s public key is used to encrypt the symmetric key only. The final ciphertext consists of the symmetric ciphertext and the encrypted symmetric key.

Hybrid encryption has the following properties:

  • Secrecy: Nobody will be able to get any information about the encrypted plaintext (except the length), unless they have access to the secret key.
  • Asymmetric: Encrypting the ciphertext can be done with the public key, but for decryption the secret key is required.
  • Randomization: The encryption is randomized. Two messages with the same plaintext will not yield the same ciphertext. This prevents attackers from knowing which ciphertext corresponds to a given plaintext.

The functionality of Hybrid Encryption is represented in Tink as a pair of primitives:

  • HybridEncrypt for encryption
  • HybridDecrypt for decryption

Context info parameter

In addition to the plaintext, encryption accepts an extra parameter, context_info, which is usually public data implicit from the context, but should be bound to the resulting ciphertext. This means that the ciphertext allows you to confirm the integrity of the context info but there are no guarantees for its secrecy or authenticity. The actual context info can be empty or null, but to ensure the correct decryption of the resulting ciphertext, the same value must be provided for decryption.

A concrete implementation of hybrid encryption can bind context info to the ciphertext in various ways, for example:

  • Use context_info as associated data input for AEAD symmetric encryption (cf. RFC 5116).
  • Use context_info as “CtxInfo" input for HKDF (if the implementation uses HKDF as key derivation function, cf. RFC 5869).

Choosing a key type

We recommend using the ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM key type for most users. This key type implements the ECIES algorithm as specified in Victor Shoup’s ISO 18033-2 standard. ECIES consists of a key encapsulation method (KEM) and a data encapsulation method (DEM).

ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM employs:

  • KEM: Elliptic-curve Diffie–Hellman over the NIST P-256 curve, with compressed ephemeral public keys and HKDF with HMAC_SHA256 as the KDF.
  • DEM: AES128_GCM with randomly generated 12-byte IV.

Minimal properties

  • Plaintext and context info can have arbitrary length (within the range 0..232 bytes)
  • Secure against adaptive chosen ciphertext attacks
  • 128-bit security for elliptic curve based schemes

Example use case

See I want to exchange data.