TLS 1.3 附加數據中的密文長度

RFC8846 說：

..and the additional data input is the record header.

  I.e.,

     additional_data = TLSCiphertext.opaque_type ||
                       TLSCiphertext.legacy_record_version ||
                       TLSCiphertext.length

但是在加密完成之前，加密文本的長度（即記錄頭中的長度欄位）是未知的。在我看來，這就像先有雞還是先有蛋的情況。問題是，我在這裡缺少什麼？

謝謝。

在加密完成之前，加密文本的長度（即記錄頭中的長度欄位）是未知的

只要知道明文的長度，就知道密文的長度。對於任何未損壞的加密機制都是如此。攻擊者可以很容易地觀察到密文的長度，如果這允許攻擊者推斷出除了長度之外的明文的任何內容，那麼它就是加密的一個弱點。

TLS 1.3 的所有標準 AEAD 機制（CCM、GCM、ChaCha20+Poly1305）的構造方式是密文是流密碼對明文的應用，後跟一次性 MAC（身份驗證標籤）。因此密文的長度是明文的長度加上機制的標籤長度（GCM、CCM 和 ChaCha20+Poly1305 為 16；CCM_8 為 8）。RFC 8846 的措辭更通用，允許 AEAD 機制具有更複雜的結構。但無論機制是什麼，都有一種方法可以從明文長度計算密文長度，儘管它可能比添加一個常數更難。

如果您在文件中搜尋“附加數據”，請點擊連結，您將得到答案；

第 5.2 節提到了這一點；

AEAD 算法將單個密鑰、隨機數、明文和要包含在身份驗證檢查中的“附加數據”作為輸入，如第 2.1 節所述

$$ RFC5116 $$

這會將您發送到 RFC5116 的第 2.1 節，您將在其中看到這一點；

關聯數據A，其中包含要認證但未加密的數據。

簡而言之；相關數據未加密，僅經過身份驗證。在不需要加密但需要唯一身份驗證的情況下，它非常有用。這就是為什麼它不是密文長度的一部分！

引用自：https://crypto.stackexchange.com/questions/89999