Streaming Authenticated Encryption with Associated Data (Streaming AEAD)

The Streaming AEAD primitive provides authenticated encryption for streaming data. It is useful when the data to be encrypted is too large to be processed in a single step. Typical use cases include encryption of large files or live data streams.

Encryption is done in segments, which are bound to their location within a ciphertext and cannot be removed or reordered. Segments from one ciphertext cannot be insert into another ciphertext. To modify an existing ciphertext, the entire data stream must be re-encrypted.¹

Decryption is fast because only a portion of the ciphertext is decrypted and authenticated at a time. Partial plaintexts are obtainable without processing the entire ciphertext.

Streaming AEAD implementations fulfill the AEAD definition and are nOAE-secure. They have the following properties:

• Secrecy: Nothing about the plaintext is known, except its length.
• 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.
• Randomization: Encryption is randomized. Two messages with the same plaintext yield different ciphertexts. Attackers cannot know which ciphertext corresponds to a given plaintext.

Associated data

Caution: Associated data is authenticated but NOT encrypted.

Streaming AEAD can be used to tie ciphertext to specific associated data. 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.

Choose a key type

We recommend AES128_GCM_HKDF_1MB for most uses. Generally:

• AES128_GCM_HKDF_1MB (or AES256_GCM_HKDF_1MB) is the faster option. It can encrypt 2⁶⁴ files with up to 2⁶⁴ bytes each. ~1 MB of memory is consumed during the encryption and decryption process.
• AES128_GCM_HKDF_4KB consumes ~4 KB of memory and is a good choice if your system doesn't have a lot of memory.
• AES128_CTR_HMAC_SHA256_1MB (or AES256_CTR_HMAC_SHA256_1MB) is a more conservative option.

Note: For 1 MB schemes, the plaintext may have any length within 0 to 2⁵¹ bytes.²

Security guarantees

Streaming AEAD implementations offer:

• CCA2 security.
• At least 80-bit authentication strength.
• The ability to encrypt at least 2⁶⁴ messages³ with a total of 2⁵¹ bytes² . No attack with up to 2³² chosen plaintexts or chosen ciphertexts has success probability larger than 2^-32.

Caution: Streaming AEAD offers no secrecy guarantees for associated data.

Example use case

See I want to encrypt large files or data streams.

---

1. A reason for this restriction is the use of the AES-GCM cipher. Encrypting a different plaintext segment at the same location would be equivalent to reusing the IV, which violates the security guarantees of AES-GCM. Another reason is that this prevents roll-back attacks, where the attacker may try to restore a previous version of the file without detection. ↩

2. 2³² segments are supported, with each segment containing segment_size - tag_size bytes of plaintext. For 1 MB segments, the total plaintext size is 2³² * (2²⁰-16) ~= 2⁵¹ bytes. ↩

3. Streaming AEAD becomes insecure when a derived key (128-bit) and nonce prefix (independent random 7-byte value) combination is repeated. We have 184-bit collision resistance, which roughly translates to 2⁶⁴ messages if we want success probability to be less than 2^-32. ↩