Criptografia autenticada de streaming com dados associados (Streaming AEAD)
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A primitiva AEAD de streaming oferece criptografia autenticada para dados de streaming. É útil quando os dados a serem criptografados são muito grandes para serem processados em
uma única etapa. Os casos de uso típicos incluem a criptografia de arquivos grandes ou transmissões de dados
ao vivo.
A criptografia é feita em segmentos, que são vinculados ao local em um
texto criptografado e não podem ser removidos nem reorganizados. Os segmentos de um texto criptografado
não podem ser inseridos em outro texto criptografado. Para modificar um texto criptografado,
todo o fluxo de dados precisa ser criptografado novamente.1
A descriptografia é rápida porque apenas uma parte do texto criptografado é descriptografada e
autenticada por vez. Textos simples parciais podem ser obtidos sem processar
todo o texto criptografado.
Secrecy: nada sobre o texto simples é conhecido, exceto o tamanho dele.
Authenticity: é impossível mudar o texto simples
que foi criptografado sem ser detectado.
Symmetric: a criptografia do texto simples e a descriptografia do texto criptografado são
feitas com a mesma chave.
Ordem aleatória: a criptografia é aleatória. Duas mensagens com o mesmo
texto simples geram textos criptografados diferentes. Os invasores não podem saber qual
texto criptografado corresponde a um determinado texto simples.
Dados associados
A primitiva AEAD de streaming pode ser usada para vincular o texto criptografado a dados
associados específicos. Suponha que você tenha um banco de dados com os
campos user-id e encrypted-medical-history. Nesse cenário, user-id
pode ser usado como dados associados ao criptografar encrypted-medical-history. Isso
impede que um invasor mova o histórico médico de um usuário para outro.
Escolher um tipo de chave
Recomendamos AES128_GCM_HKDF_1MB para a maioria dos usos. De modo geral:
AES128_GCM_HKDF_1MB (ou AES256_GCM_HKDF_1MB) é a opção mais rápida. Ele pode
codificar 264 arquivos com até 264 bytes cada. Cerca de 1 MB de
memória é consumido durante o processo de criptografia e descriptografia.
AES128_GCM_HKDF_4KB consome cerca de 4 KB de memória e é uma boa escolha se o
sistema não tiver muita memória.
AES128_CTR_HMAC_SHA256_1MB (ou AES256_CTR_HMAC_SHA256_1MB) é uma opção mais
conservadora.
Garantias de segurança
As implementações de AEAD em streaming oferecem:
Segurança CCA2.
Força de autenticação de pelo menos 80 bits.
A capacidade de criptografar pelo menos 264 mensagens3 com um total de
251 bytes2 . Nenhum ataque com até 232
textos simples ou textos cifrados escolhidos tem uma probabilidade de sucesso maior
que
2-32.
Uma razão para essa restrição é o uso da cifra AES-GCM. Criptografar um segmento de texto simples diferente no mesmo local seria equivalente a reutilizar o IV, o que viola as garantias de segurança do AES-GCM. Outra razão é que isso evita ataques de reversão, em que o invasor pode tentar restaurar uma versão anterior do arquivo sem ser detectado. ↩
Há suporte para 232 segmentos, com cada segmento contendo segment_size - tag_size bytes de texto simples. Para segmentos de 1 MB, o tamanho total de texto simples é 232 * (220-16) ~= 251 bytes. ↩
O streaming AEAD se torna inseguro quando uma combinação de chave derivada (128 bits) e prefixo de valor de uso único (valor aleatório independente de 7 bytes) é repetida. Temos uma resistência a colisões de 184 bits, o que equivale a 264 mensagens se quisermos que a probabilidade de sucesso seja menor que 2-32. ↩
[null,null,["Última atualização 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)"]]
