Mã hoá xác thực truyền trực tuyến với dữ liệu liên kết (Truyền trực tuyến AEAD)
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Phương thức gốc AEAD truyền trực tuyến cung cấp tính năng mã hoá đã xác thực cho dữ liệu truyền trực tuyến. Phương thức này hữu ích khi dữ liệu cần mã hoá quá lớn để xử lý trong một bước. Các trường hợp sử dụng điển hình bao gồm mã hoá tệp lớn hoặc luồng dữ liệu trực tiếp.
Quá trình mã hoá được thực hiện theo các phân đoạn, các phân đoạn này được liên kết với vị trí của chúng trong văn bản đã mã hoá và không thể xoá hoặc sắp xếp lại. Không thể chèn các đoạn từ một văn bản đã mã hoá vào một văn bản đã mã hoá khác. Để sửa đổi văn bản đã mã hoá hiện có, toàn bộ luồng dữ liệu phải được mã hoá lại.1
Quá trình giải mã diễn ra nhanh chóng vì mỗi lần chỉ giải mã và xác thực một phần văn bản đã mã hoá. Bạn có thể lấy một phần văn bản thô mà không cần xử lý toàn bộ văn bản đã mã hoá.
Secrecy: Không biết gì về văn bản thô, ngoại trừ độ dài.
Authenticity: Không thể thay đổi văn bản thô đã mã hoá cơ bản của văn bản đã mã hoá mà không bị phát hiện.
Symmetric: Việc mã hoá văn bản thô và giải mã văn bản đã mã hoá được thực hiện bằng cùng một khoá.
Sắp xếp ngẫu nhiên: Quá trình mã hoá được sắp xếp ngẫu nhiên. Hai thông điệp có cùng văn bản thô sẽ tạo ra các văn bản đã mã hoá khác nhau. Kẻ tấn công không thể biết văn bản đã mã hoá nào tương ứng với một văn bản thô nhất định.
Dữ liệu liên quan
Bạn có thể sử dụng nguyên hàm AEAD truyền trực tuyến để liên kết văn bản đã mã hoá với dữ liệu liên kết cụ thể. Giả sử bạn có một cơ sở dữ liệu với các trường user-id và encrypted-medical-history: Trong trường hợp này, user-id có thể được dùng làm dữ liệu liên kết khi mã hoá encrypted-medical-history. Điều này ngăn kẻ tấn công chuyển hồ sơ y tế từ người dùng này sang người dùng khác.
Chọn loại khoá
Bạn nên sử dụng AES128_GCM_HKDF_1MB cho hầu hết các trường hợp sử dụng. Nhìn chung:
AES128_GCM_HKDF_1MB (hoặc AES256_GCM_HKDF_1MB) là tuỳ chọn nhanh hơn. Phương thức này có thể mã hoá 264 tệp, mỗi tệp có kích thước tối đa là 264 byte. ~1 MB bộ nhớ sẽ được sử dụng trong quá trình mã hoá và giải mã.
AES128_GCM_HKDF_4KB tiêu thụ khoảng 4 KB bộ nhớ và là một lựa chọn phù hợp nếu hệ thống của bạn không có nhiều bộ nhớ.
AES128_CTR_HMAC_SHA256_1MB (hoặc AES256_CTR_HMAC_SHA256_1MB) là một tuỳ chọn bảo thủ hơn.
Cam kết bảo mật
Các phương thức triển khai AEAD trực tuyến cung cấp:
Bảo mật CCA2.
Độ mạnh của chế độ xác thực tối thiểu là 80 bit.
Khả năng mã hoá ít nhất 264 thông báo3 với tổng số 251 byte2 . Không có cuộc tấn công nào với tối đa 232 văn bản thô hoặc văn bản đã mã hoá được chọn có xác suất thành công lớn hơn 2-32.
Một lý do dẫn đến quy định hạn chế này là việc sử dụng thuật toán mật mã AES-GCM. Việc mã hoá một đoạn văn bản thô khác tại cùng một vị trí sẽ tương đương với việc sử dụng lại IV, điều này vi phạm các cam kết bảo mật của AES-GCM. Một lý do khác là việc này ngăn chặn các cuộc tấn công quay lại, trong đó kẻ tấn công có thể cố gắng khôi phục phiên bản tệp trước đó mà không bị phát hiện. ↩
Hỗ trợ 232 phân đoạn, mỗi phân đoạn chứa segment_size - tag_size byte văn bản thuần tuý. Đối với các phân đoạn 1 MB, tổng kích thước văn bản thô là 232 * (220-16) ~= 251 byte. ↩
AEAD truyền trực tuyến trở nên không an toàn khi tổ hợp khoá phái sinh (128 bit) và tiền tố số chỉ dùng một lần (giá trị 7 byte ngẫu nhiên độc lập) được lặp lại. Chúng ta có khả năng chống xung đột 184 bit, tương đương với 264 thông báo nếu muốn xác suất thành công thấp hơn 2-32. ↩
[null,null,["Cập nhật lần gần đây nhất: 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)"]]
