Crittografia autenticata in streaming con dati associati (AEAD streaming)
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
La primitiva AEAD in streaming fornisce crittografia autenticata per i dati in streaming. È utile quando i dati da criptare sono troppo grandi per essere elaborati in un singolo passaggio. I casi d'uso tipici includono la crittografia di file di grandi dimensioni o stream di dati in tempo reale.
La crittografia viene eseguita in segmenti, che sono legati alla loro posizione all'interno di un testo cifrato e non possono essere rimossi o riordinati. I segmenti di un testo cifrato
non possono essere inseriti in un altro testo cifrato. Per modificare un testo cifrato esistente,
l'intero stream di dati deve essere criptato di nuovo.1
La decrittografia è rapida perché viene decriptata e autenticata solo una parte del testo cifrato alla volta. I testi non criptati parziali sono ottenibili senza elaborare
l'intero testo criptato.
Le implementazioni AEAD in streaming soddisfano la definizione AEAD e sono sicure nOAE. Hanno le seguenti proprietà:
Secrecy: non è nota alcuna informazione sul testo non cifrato, tranne la sua lunghezza.
Authenticity: è impossibile modificare il testo normale criptato
sottostante il testo cifrato senza che ciò venga rilevato.
Symmetric: la crittografia del testo in chiaro e la decrittografia del testo cifrato vengono eseguite con la stessa chiave.
Randomizzazione: la crittografia è randomizzata. Due messaggi con lo stesso testo in chiaro generano crittogrammi diversi. Gli aggressori non possono sapere quale messaggio cifrato corrisponde a un determinato testo non criptato.
Dati associati
La primitiva AEAD in streaming può essere utilizzata per collegare il testo cifrato a dati associati specifici. Supponiamo di avere un database con i campi user-id e encrypted-medical-history: in questo scenario, user-id può essere utilizzato come dati associati durante la crittografia di encrypted-medical-history. In questo modo, un malintenzionato non può spostare la storia clinica da un utente all'altro.
Scegli un tipo di chiave
Per la maggior parte degli utilizzi, consigliamo AES128_GCM_HKDF_1MB. In generale:
AES128_GCM_HKDF_1MB (o AES256_GCM_HKDF_1MB) è l'opzione più veloce. Può
criptare 264 file con un massimo di 264 byte ciascuno. Durante il processo di crittografia e decrittografia viene utilizzato circa 1 MB di memoria.
AES128_GCM_HKDF_4KB consuma circa 4 KB di memoria ed è una buona scelta se il tuo sistema non ha molta memoria.
AES128_CTR_HMAC_SHA256_1MB (o AES256_CTR_HMAC_SHA256_1MB) è un'opzione più conservativa.
Garanzie di sicurezza
Le implementazioni AEAD in streaming offrono:
Sicurezza CCA2.
Efficacia dell'autenticazione di almeno 80 bit.
La possibilità di criptare almeno 264 messaggi3 per un totale di
251 byte2 . Nessun attacco con fino a 232
codici in chiaro o cifrati scelti ha una probabilità di successo superiore
a
2-32.
Un motivo di questa limitazione è l'utilizzo della crittografia AES-GCM. La crittografia di un segmento di testo non cifrato diverso nella stessa posizione equivarrebbe al riutilizzo dell'IV, che viola le garanzie di sicurezza di AES-GCM. Un altro motivo è che in questo modo vengono evitati gli attacchi di roll-back, in cui l'aggressore potrebbe tentare di ripristinare una versione precedente del file senza essere rilevato. ↩
Sono supportati 2 segmenti 32, ciascuno contenente segment_size - tag_size byte di testo normale. Per i segmenti di 1 MB, la dimensione totale del testo non cifrato è 232 * (220-16) ~= 251 byte. ↩
La crittografia AEAD in streaming diventa non sicura quando viene ripetuta una combinazione di una chiave derivata (128 bit) e un prefisso nonce (valore casuale indipendente di 7 byte). Abbiamo una resistenza alle collisioni di 184 bit, che si traduce approssimativamente in 264 messaggi se vogliamo che la probabilità di successo sia inferiore a 2-32. ↩
[null,null,["Ultimo aggiornamento 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)"]]
