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:
context_infoas associated data input for AEAD symmetric encryption (cf. RFC 5116).
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 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).
- 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.
- 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