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.
- Asymmetry: 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_infoas associated data input for AEAD symmetric encryption (cf. RFC 5116). - Use
context_infoas “CtxInfo" input for HKDF (if the implementation uses HKDF as key derivation function, cf. RFC 5869).
Choosing a key type
We recommend using the DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM key type for most users. This key type implements the Hybrid Public Key Encryption (HPKE) standard as specified in RFC 9180. HPKE consists of a key encapsulation mechanism (KEM), a key derivation function (KDF), and an authenticated encryption with associated data (AEAD) algorithm.
DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM specifically employs:
- KEM: Diffie–Hellman over Curve25519 with HKDF-SHA-256 to derive the shared secret.
- KDF: HKDF-SHA-256 to derive the sender/receiver context.
- AEAD: AES-256-GCM with 12-byte nonces generated according to the HPKE standard.
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