Streaming Authenticated Encryption with Associated Data (Streaming AEAD)
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Das Streaming-AEAD-Primitive bietet eine authentifizierte Verschlüsselung für Streamingdaten. Sie ist nützlich, wenn die zu verschlüsselnden Daten zu groß sind, um in einem einzigen Schritt verarbeitet zu werden. Typische Anwendungsfälle sind die Verschlüsselung großer Dateien oder Live-Datenstreams.
Die Verschlüsselung erfolgt in Segmenten, die an ihren Speicherort innerhalb eines Geheimtexts gebunden sind und nicht entfernt oder neu angeordnet werden können. Segmente aus einem Geheimtext können nicht in einen anderen Geheimtext eingefügt werden. Wenn ein vorhandener Geheimtext geändert werden soll, muss der gesamte Datenstream noch einmal verschlüsselt werden.1
Die Entschlüsselung ist schnell, da jeweils nur ein Teil des Geheimtexts entschlüsselt und authentifiziert wird. Teilweise Klartexte können ohne Verarbeitung des gesamten Geheimtexts abgerufen werden.
Streaming-AEAD-Implementierungen erfüllen die AEAD-Definition und sind nOAE-sicher. Sie haben folgende Eigenschaften:
Secrecy Außer der Länge ist nichts über den Klartext bekannt.
Authenticity Es ist nicht möglich, den verschlüsselten Klartext, der dem Geheimtext zugrunde liegt, unbemerkt zu ändern.
Symmetric Der Klartext wird mit demselben Schlüssel verschlüsselt und der Geheimtext wird mit demselben Schlüssel entschlüsselt.
Zufälligkeit: Die Verschlüsselung wird zufällig durchgeführt. Zwei Nachrichten mit demselben Klartext liefern unterschiedliche Geheimtexte. Angreifer können nicht wissen, welcher Geheimtext einem bestimmten Klartext entspricht.
Verknüpfte Daten
Mit der Streaming-AEAD-Primitiv kann Geheimtext mit bestimmten zugehörigen Daten verknüpft werden. Angenommen, Sie haben eine Datenbank mit den Feldern user-id und encrypted-medical-history. In diesem Fall kann user-id beim Verschlüsseln von encrypted-medical-history als verknüpfte Daten verwendet werden. Dadurch wird verhindert, dass ein Angreifer einen medizinischen Verlauf von einem Nutzer zu einem anderen verschieben kann.
Schlüsseltyp auswählen
Wir empfehlen für die meisten Anwendungsfälle AES128_GCM_HKDF_1MB. Allgemein gilt:
AES128_GCM_HKDF_1MB (oder AES256_GCM_HKDF_1MB) ist die schnellere Option. Es können 264 Dateien mit jeweils bis zu 264 Byte verschlüsselt werden. Während der Verschlüsselung und Entschlüsselung wird etwa 1 MB Arbeitsspeicher verbraucht.
AES128_GCM_HKDF_4KB belegt etwa 4 KB Arbeitsspeicher und ist eine gute Wahl, wenn Ihr System nicht viel Arbeitsspeicher hat.
AES128_CTR_HMAC_SHA256_1MB (oder AES256_CTR_HMAC_SHA256_1MB) ist eine konservativere Option.
Sicherheitsgarantien
Streaming-AEAD-Implementierungen bieten:
CCA2-Sicherheit
Mindestens 80-Bit-Authentifizierungsstärke.
Es können mindestens 264 Nachrichten3 mit insgesamt 251 Byte2 verschlüsselt werden . Kein Angriff mit bis zu 232 ausgewählten Klartexten oder ausgewählten Geheimtexten hat eine Erfolgswahrscheinlichkeit, die größer als 2−32 ist.
Ein Grund für diese Einschränkung ist die Verwendung der AES-GCM-Chiffre. Das Verschlüsseln eines anderen Klartextsegments am selben Speicherort würde der Wiederverwendung des IV entsprechen, was gegen die Sicherheitsgarantien von AES-GCM verstößt. Außerdem werden so Rollback-Angriffe verhindert, bei denen der Angreifer versucht, eine frühere Version der Datei unbemerkt wiederherzustellen. ↩
Es werden 232 Segmente unterstützt, wobei jedes Segment segment_size - tag_size Byte Klartext enthält. Bei 1-MB-Segmenten beträgt die Gesamtgröße des Klartexts 232 * (220 – 16) ≈ 251 Byte. ↩
Streaming AEAD wird unsicher, wenn eine Kombination aus abgeleitetem Schlüssel (128 Bit) und Nonce-Prefix (unabhängiger, zufälliger 7-Byte-Wert) wiederholt wird. Wir haben eine Kollisionsresistenz von 184 Bit, was ungefähr 264 Nachrichten entspricht, wenn die Erfolgswahrscheinlichkeit unter 2−32 liegen soll. ↩
[null,null,["Zuletzt aktualisiert: 2025-07-25 (UTC)."],[[["\u003cp\u003eStreaming AEAD encrypts large data streams or files securely in segments, ensuring authenticity and confidentiality.\u003c/p\u003e\n"],["\u003cp\u003eIt offers strong security guarantees, including CCA2 security, at least 80-bit authentication strength, and resistance to common attacks.\u003c/p\u003e\n"],["\u003cp\u003eAssociated data is authenticated but not encrypted, preventing unauthorized data manipulation but not revealing its content.\u003c/p\u003e\n"],["\u003cp\u003eTink recommends AES128_GCM_HKDF_1MB for most use cases due to its speed and large data capacity, with alternative options for memory-constrained environments.\u003c/p\u003e\n"],["\u003cp\u003eModifying existing ciphertext requires re-encryption of the entire stream, maintaining data integrity and preventing rollback attacks.\u003c/p\u003e\n"]]],["Streaming AEAD encrypts large data streams in segments, ensuring authenticity and secrecy, but only the plaintext is encrypted, associated data is not. Encryption segments are bound to their location and cannot be reordered or moved. Decryption allows partial ciphertext processing. The recommended key type is AES128_GCM_HKDF_1MB. Streaming AEAD offers CCA2 security, at least 80-bit authentication strength, and can encrypt at least 2^64 messages with a total of 2^51 bytes. Re-encrypting the whole stream is needed to modify the ciphertext.\n"],null,["# Streaming Authenticated Encryption with Associated Data (Streaming AEAD)\n\nThe Streaming AEAD primitive provides authenticated encryption for streaming\ndata. It is useful when the data to be encrypted is too large to be processed in\na single step. Typical use cases include encryption of large files or live data\nstreams.\n\nEncryption is done in segments, which are bound to their location within a\nciphertext and cannot be removed or reordered. Segments from one ciphertext\ncannot be inserted into another ciphertext. To modify an existing ciphertext,\nthe entire data stream must be re-encrypted.^[1](#fn1)^\n\nDecryption is fast because only a portion of the ciphertext is decrypted and\nauthenticated at a time. Partial plaintexts are obtainable without processing\nthe entire ciphertext.\n\nStreaming AEAD implementations fulfill the [AEAD\ndefinition](https://www.cs.ucdavis.edu/%7Erogaway/papers/ad.html) and are\n[nOAE-secure](https://eprint.iacr.org/2015/189.pdf). They have the following\nproperties:\n\n- **Secrecy**: Nothing about the plaintext is known, except its length.\n- **Authenticity**: It is impossible to change the encrypted plaintext underlying the ciphertext without being detected.\n- **Symmetric**: Encrypting the plaintext and decrypting the ciphertext is done with the same key.\n- **Randomization**: Encryption is randomized. Two messages with the same plaintext yield different ciphertexts. Attackers cannot know which ciphertext corresponds to a given plaintext.\n\n### Associated data\n\n| **Caution:** Associated data is authenticated but *NOT* encrypted.\n\nThe Streaming AEAD primitive can be used to [tie ciphertext to specific\nassociated data](/tink/bind-ciphertext). Suppose you have a database with the\nfields `user-id` and `encrypted-medical-history`: In this scenario, `user-id`\ncan be used as associated data when encrypting `encrypted-medical-history`. This\nprevents an attacker from moving medical history from one user to another.\n\n### Choose a key type\n\nWe recommend **AES128_GCM_HKDF_1MB** for most uses. Generally:\n\n- [AES-GCM-HKDF](/tink/streaming-aead/aes_gcm_hkdf_streaming)\n - AES128_GCM_HKDF_1MB (or AES256_GCM_HKDF_1MB) is the faster option. It can encrypt 2^64^ files with up to 2^64^ bytes each. \\~1 MB of memory is consumed during the encryption and decryption process.\n - AES128_GCM_HKDF_4KB consumes \\~4 KB of memory and is a good choice if your system doesn't have a lot of memory.\n- [AES-CTR HMAC](/tink/streaming-aead/aes_ctr_hmac_streaming)\n - AES128_CTR_HMAC_SHA256_1MB (or AES256_CTR_HMAC_SHA256_1MB) is a more conservative option.\n\n| **Note:** For 1 MB schemes, the plaintext may have any length within 0 to 2^51^ bytes.^[2](#fn2)^\n\n### Security guarantees\n\nStreaming AEAD implementations offer:\n\n- CCA2 security.\n- At least 80-bit authentication strength.\n- The ability to encrypt at least 2^64^ messages^[3](#fn3)^ with a total of 2^51^ bytes[^2^](#fn2) . No attack with up to 2^32^ chosen plaintexts or chosen ciphertexts has a probability of success larger than 2^-32^.\n\n| **Caution:** **Streaming AEAD offers no secrecy guarantees for associated data.**\n\n### Example use case\n\nSee [I want to encrypt large files or data\nstreams](/tink/encrypt-large-files-or-data-streams). \n\n*** ** * ** ***\n\n1. 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. [↩](#fnref1)\n\n2. 2^32^ segments are supported, with each segment containing `segment_size - tag_size` bytes of plaintext. For 1 MB segments, the total plaintext size is 2^32^ \\* (2^20^-16) \\~= 2^51^ bytes. [↩](#fnref2)\n\n3. 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^64^ messages if we want success probability to be less than 2^-32^. [↩](#fnref3)"]]
