The Deterministic Authenticated Encryption with Associated Data (Deterministic
AEAD) primitive provides encryption with a *deterministic* property: encrypting
the same data always yields the same ciphertext. This type of encryption is
useful for key wrapping or for some schemes for searching on encrypted data (see
[RFC 5297, Section
1.3](https://tools.ietf.org/html/rfc5297#section-1.3)
for more info). Because of its deterministic property, implementations of this
primitive can lead to loss of secrecy because an attacker only needs to find out
the ciphertext for a given message to identify other instances of that message.

Deterministic AEAD has the following properties:

- **Secrecy**: Nothing about the plaintext is known, except its length and the equality of repeated plaintexts.
- **Authenticity**: It is impossible to change the encrypted plaintext underlying the ciphertext without being detected.
- **Symmetric**: Encrypting the plaintext and decrypting the ciphertext is done with the same key.
- **Deterministic**: As long as the primary key is not changed, encrypting a plaintext twice with the same parameters results in the same ciphertext.

> [!NOTE]
> **Note:** Deterministic AEAD protects data almost as well as the normal AEAD primitive. However, if you send the same message twice, an attacker can notice that the two messages are equal. If this is not the intended behaviour, see [AEAD](https://developers.google.com/tink/aead).

### Associated data

> [!CAUTION]
> **Caution:** Associated data is authenticated but *NOT* encrypted.

Deterministic AEAD can be used to [tie ciphertext to specific associated
data](https://developers.google.com/tink/bind-ciphertext). Suppose you have a database with the fields `user-id`
and `encrypted-medical-history`. In this scenario, `user-id` can be used as
associated data when encrypting `encrypted-medical-history`. This prevents an
attacker from moving medical history from one user to another.

Associated data is optional. If specified, decryption only succeeds if the same
associated data is passed to both encrypt and decrypt calls.

### Choose a key type

We recommend the **AES256_SIV** key type for all use cases.

> [!NOTE]
> **Note:** Tink doesn't offer AES128_SIV because it doesn't provide 128-bit security in multi-user scenarios.

### Security guarantees

- At least 80-bit authentication strength.
- The plaintext and associated data can have arbitrary lengths (within the range 0..2^32^ bytes).
- 128-bit security level against key recovery attacks, and also in multi-user attacks with up to 2^32^ keys --- that means if an adversary obtains 2^32^ ciphertexts of the same message encrypted under 2^32^ keys, they need to do 2^128^ computations to obtain a single key.
- The ability to safely encrypt 2^38^ messages, provided each is less than 1MB in length.

> [!CAUTION]
> **Caution:** **Deterministic AEAD offers no secrecy guarantees for associated
> data.**

### Example use case

See I want to [encrypt data deterministically](https://developers.google.com/tink/deterministic-encryption) and
I want to [bind ciphertext to its context](https://developers.google.com/tink/bind-ciphertext).