Streaming authentifié du chiffrement avec des données associées (AEAD en flux continu)
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
La primitive AEAD en streaming fournit un chiffrement authentifié pour les données en streaming. Elle est utile lorsque les données à chiffrer sont trop volumineuses pour être traitées en une seule étape. Les cas d'utilisation typiques incluent le chiffrement de fichiers volumineux ou de flux de données en direct.
Le chiffrement est effectué par segments, qui sont liés à leur emplacement dans un texte chiffré et ne peuvent pas être supprimés ni réorganisés. Les segments d'un texte chiffré ne peuvent pas être insérés dans un autre texte chiffré. Pour modifier un texte chiffré existant, l'intégralité du flux de données doit être ré-chiffrée.1
Le déchiffrement est rapide, car seule une partie du texte chiffré est déchiffrée et authentifiée à la fois. Les textes bruts partiels sont disponibles sans traiter l'intégralité du texte chiffré.
Secrecy: rien sur le texte brut n'est connu, sauf sa longueur.
Authenticity: il est impossible de modifier le texte brut chiffré sous-jacent au texte chiffré sans que la modification ne soit détectable.
Symmetric: le chiffrement du texte brut et le déchiffrement du texte chiffré s'effectuent avec la même clé.
Randomisation: le chiffrement est aléatoire. Deux messages comportant le même texte brut génèrent des textes chiffrés différents. Les pirates informatiques ne peuvent pas savoir quel texte chiffré correspond à un texte brut donné.
Données associées
La primitive AEAD en streaming peut être utilisée pour lier le texte chiffré à des données associées spécifiques. Supposons que vous ayez une base de données avec les champs user-id et encrypted-medical-history: dans ce scénario, user-id peut être utilisé en tant que données associées lors du chiffrement de encrypted-medical-history. Cela empêche un pirate informatique de transférer l'historique médical d'un utilisateur à un autre.
Choisir un type de clé
Nous recommandons AES128_GCM_HKDF_1MB pour la plupart des utilisations. En général:
AES128_GCM_HKDF_1MB (ou AES256_GCM_HKDF_1MB) est l'option la plus rapide. Il peut chiffrer deux fichiers 64 de 2 64 octets chacun. Environ 1 Mo de mémoire est consommé pendant le processus de chiffrement et de déchiffrement.
AES128_GCM_HKDF_4KB consomme environ 4 ko de mémoire et constitue un bon choix si votre système ne dispose pas de beaucoup de mémoire.
AES128_CTR_HMAC_SHA256_1MB (ou AES256_CTR_HMAC_SHA256_1MB) est une option plus conservatrice.
Garanties de sécurité
Les implémentations AEAD en streaming offrent les avantages suivants:
Sécurité CCA2
Niveau d'authentification d'au moins 80 bits
Capacité de chiffrer au moins 264 messages3 pour un total de 251 octets2 . Aucune attaque avec jusqu'à 232 textes bruts ou chiffrés choisis n'a une probabilité de succès supérieure à 2-32.
Cette restriction est due à l'utilisation du chiffrement AES-GCM. Le chiffrement d'un autre segment de texte brut au même emplacement équivaut à la réutilisation de l'IV, ce qui enfreint les garanties de sécurité d'AES-GCM. Cela permet également d'éviter les attaques de rollback, où le pirate informatique peut essayer de restaurer une version précédente du fichier sans être détecté. ↩
2 32 segments sont acceptés, chaque segment contenant segment_size - tag_size octets de texte brut. Pour les segments de 1 Mo, la taille totale du texte brut est 232 * (220-16) ~= 251 octets. ↩
Le streaming AEAD devient non sécurisé lorsqu'une combinaison de clé dérivée (128 bits) et de préfixe de nonce (valeur aléatoire indépendante de 7 octets) est répétée. Nous disposons d'une résistance aux collisions de 184 bits, ce qui correspond à environ 264 messages si nous voulons que la probabilité de réussite soit inférieure à 2-32. ↩
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[null,null,["Dernière mise à jour le 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)"]]
