是否有用於為 AES GCM 生成唯一 IV 的 TLS 擴展？

由於重用 IV 對 AES GCM 來說是死亡，因此在 TLS 連接狀態下使用固定 IV 似乎是一個非常糟糕的主意。使用 salt + counter 方法似乎不是一個好主意，因為攻擊者可以監視第一個密文記錄交換並從那裡跟踪。有沒有擴展來解決這個問題？RFC 顯然沒有幫助。

您可以查看這個答案，其中提到了 IV 是如何在TLS 1.2中為 GCM 密碼生成的

… 是一個 AEAD 密碼，所以它是GenericAEADCipher的形式：

struct {
     opaque nonce_explicit[SecurityParameters.record_iv_length];
     aead-ciphered struct {
         opaque content[TLSCompressed.length];
     };
  } GenericAEADCipher;

在這裡，nonce_explicit 包含 8 個字節的 nonce，你將它與來自密鑰派生（4 個字節）的“固定 IV”結合起來，然後你得到 12 個字節的 IV 用於 AES-GCM 模式加密。（請注意，您只發送 了 IV 的最後8 個字節）。

此外，來自RFC 5288（用於 TLS 的 AES 伽羅瓦計數器模式 (GCM) 密碼套件）

6.1。計數器重用

AES-GCM 安全要求計數器永遠不會被重複使用。第 3 節中的 IV 構造旨在防止計數器重用。

來自RFC 5288 的第 3 節：

“nonce”應為 12 個字節長，由以下兩部分組成：（這是“部分顯式”nonce 的範例；參見 第 3.2.1 節$$ RFC5116 $$).

struct {
     opaque salt[4];
     opaque nonce_explicit[8];
} GCMNonce;

salt 是 nonce 的“隱含”部分，不會在數據包中發送。相反，鹽是作為握手過程的一部分生成的：它是 client_write_IV（當客戶端發送時）或 server_write_IV（當伺服器發送時）。鹽長度 (SecurityParameters.fixed_iv_length) 是 4 個八位字節。

nonce_explicit 是 nonce 的“顯式”部分。它由發送者選擇，並在 GenericAEADCipher.nonce_explicit 欄位中的每個 TLS 記錄中攜帶。nonce_explicit 長度 (SecurityParameters.record_iv_length) 為 8 個八位字節。

對於任何固定密鑰的 GCM 加密函式的每次不同呼叫，nonce_explicit 的每個值都必須是不同的。未能滿足此唯一性要求會顯著降低安全性。nonce_explicit 可以是 64 位序列號。

因此，以這種方式可以防止在 TLS 的 GCM 密碼套件中重用相同的 IV。

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