根據 RFC 4106 AES-GCM 中 IV 的大小
RFC 4106 規定了 nonce。它包含一個大小為 4 個八位字節的鹽和一個大小為 8 個八位字節的 iv。此外，RFC 指定在通過 Internet 密鑰交換 (IKE) 建立的安全關聯的開頭分配鹽，並且鹽值是恆定的。但是所有關於 AES-GCM 的大多數實現和描述都將 iv 指定為 12 個八位字節，並且沒有考慮鹽值。
AES-GCM 將輸入作為密鑰、IV、明文和附加認證數據 (AAD)。AES-GMAC 是 AES-GCM 的一種變體，它通過將明文保持為零位來提供數據身份驗證。
我對 AES-GCM 模式的其他問題是。
- 我知道 AES-GCM 可用於數據的身份驗證，我們可以通過忽略身份驗證僅使用 AES-GCM 模式進行加密嗎？
- 是否必須使用 iv 進行使用 AES-GCM 的加密？
- AES-GMAC 的允許變體有哪些，例如 AES-GMAC128、AES-GMAC256 等？
kelalaka 回答了您的問題，但我確實相信有些事情需要澄清：
RFC 4106 規定了 nonce。它包含一個大小為 4 個八位字節的鹽和一個大小為 8 個八位字節的 iv。此外，RFC 指定在通過 Internet 密鑰交換 (IKE) 建立的安全關聯的開頭分配鹽，並且鹽值是恆定的。但是所有關於 AES-GCM 的大多數實現和描述都將 iv 指定為 12 個八位字節，並且沒有考慮鹽值。
首先，澄清術語（至少，我將在下面的回答中使用的術語）：
- Nonce - 這是傳遞給 GCM 常式的（通常為 96 位）值
- IV - 這是數據包中的值 - GCM 的 IPsec 使用 64 位 IV
- Salt - 這是配方中包含的用於生成 nonce 的附加值。
RFC 4106 專門關於如何在 IPsec 中使用 GCM；因此，它具有生成 GCM 所需的隨機數（您將其稱為“iv”）的配方。它通過加密器選擇的 8 個字節（他將其放在數據包內的“iv 欄位”中，解密器從數據包中提取）和 4 個字節用於密鑰派生（“鹽”）並連接他們。
這是特定於 IPsec 的（實際上，TLS 使用 GCM 做同樣的事情）；其他使用 GCM 的協議可能會以不同的方式生成（和通信）它們的 nonce。因為加密常式通常與協議無關，所以他們不會內置特定於 IPsec 的配方。相反，他們會假設某些特定於協議的東西會生成隨機數，並將整個隨機數傳入。
至於為什麼 IPsec 使用這個特定的配方來生成 GCM 隨機數，嗯，它是為了阻止潛在的多目標攻擊。假設攻擊者擁有大量 GCM 加密會話，並且他想恢復其中一個的內容（並不真正關心它是哪一個）。進一步假設 GCM 實現對每個會話使用相同的 IV（例如，第一個加密數據包可能總是使用 0 的 IV）。然後，攻擊者可能會嘗試猜測一個 AES 密鑰，並生成 GCM 隱私密鑰流，並查看是否為任何會話的初始數據包提供了正確的密鑰流（這在合理的假設下是有效的）。如果他能做到這一點，那就意味著，對於 128 位密鑰和 $ N $ 會議，他預期的打破其中一個會議的工作是 $ 2^{128}/N $ 試用解密，這比我們想要的要少。但是，通過包含 32 位鹽（在會話之間有所不同），這個預期的工作量增加到 $ 2^{160}/N $ （因為他必須猜鹽和密鑰）；特別是，這意味著這種多目標攻擊實際上比簡單的蠻力攻擊效率低，除非 $ N > 2^{32} $ , 這是相當多的。請注意，這種鹽實際上並不能幫助抵禦針對單個會話的暴力攻擊。它也不疼。而且，它並不一定要保密（但是，我們也沒有什麼特別的理由必須不遺餘力地發布它……）
1.我知道AES-GCM可以用於數據的認證，我們可以通過忽略認證只使用AES-GCM模式進行加密嗎？
讓我們記住，AES-GCM是一種帶有關聯數據的認證加密 (AEAD)，它使用
- CTR 模式下的 AES 用於機密性，只能提供 CPA 安全性
- 用於完整性和身份驗證的 GMAC，它是基於稱為 GHASH 的多項式雜湊函式的Wegman-Carter MAC 。
該組合是一種先加密後 MAC方式。
當然 -不建議- 可以通過簡單地丟棄身份驗證標籤來使用無需身份驗證的 AES-GCM。由於 GCM 使用前兩個計數器，因此如果您從 2 開始計數器，這將等於 CTR 。
人們會遇到一些問題，主要是使用將生成並需要標籤的標準實現的性能。可能需要生成它、發送它、提供給解密器，並忽略任何標籤錯誤！等待！或者可能需要修改原始碼。
通過不使用 GCM 部分，最多只能獲得機密性 CPA 安全性，而是可以使用 CTR 模式進行機密性。不需要 GCM 部分。只需使用普通 CTR 模式，這將減少 GCM 計算的處理時間。這在現代密碼學中是不可取的。至少
- IND-CCA2——自適應選擇密文攻擊下的密文不可區分性
是必須的。
2. 使用 AES-GCM 加密是否必須使用 iv？
(IV,key) 對不能多次使用。如果 IV 使用相同的密鑰重複使用，它將導致像兩次填充一樣的嬰兒床拖動攻擊，並且它可能會導致簽名偽造的災難性失敗。
如果您可以保證您將始終使用新密鑰，那麼您可以保持 IV 固定甚至為零。這也是不可取的，因為您正在降低 IV-Key 對的衝突機率，並且作者也不建議這樣做。生成後會發生0機率的碰撞 $ 2^{64} $ 鍵而不是 $ 2^{128} $ 如果 IV 和加密密鑰是隨機生成的。如果我們堅持 RFC 4106 那麼 $ 2^{112} $ 因為它使用 92 位 IV（RFC 4106 使用 nonce 而不是 IV 不與 ESP 的 IV 混合。）
3. AES-GMAC 允許的變體有哪些，例如 AES-GMAC128、AES-GMAC256 等？
RFC 4106 僅提及 AES-GCM。如果你想使用它，你只有 GCM。
GMAC（Galois 消息驗證碼）是 GCM 的一種僅驗證變體，可以形成增量消息驗證碼。GCM 和 GMAC 在NIST 800-38d中標準化。
AES-GCM 也用於只有 5 個密碼套件的 TLS 1.3。
但是所有關於 AES-GCM 的大多數實現和描述都將 iv 指定為 12 個八位字節，並且沒有考慮鹽值。
NIST GCM 規範(NIST.SP.800-38D)建議使用 12 個八位字節，如果您使用 16 個八位字節或更一般地提供不等於 12 字節的隨機數，那麼它將使用 GHASH 進行處理，大小將為 12-之後的字節。
if len(IV) = 96 then J_0 = IV || 0^{31}1 else J_0=GHASH_H(IV||0^{s+64}||len(IV_64))RFC 4106中定義的鹽。NIST 是政府機構，如果您在美國，則需要使用 NIST 標準才能兼容並具有競爭力。
salt 欄位是一個四字節的值，在安全關聯開始時分配，然後在安全關聯的生命週期內保持不變。
所以它特定於協議。