AES-GCM 規範是否要求將標籤大小綁定到 GCM 上下文？

GCM 規範（NIST SP 800-38D）是否需要為 GCM 算法的實例（通常固定特定的 GCM 密鑰）固定標籤大小？

換種方式問，以下是否合法遵守 GCM 規範？

GitHub 上正在進行討論- 也許有知識的人可以發表評論。

// pseudocode
var one_gcm = new AesGcm(key); key is a legit key of 16/24/32 bytes
var (ciphertext, tag16) = one_gcm.Encrypt(plaintext); // produces 16-byte tag
var truncated_tag12 = tag16.Slice(0,12); // truncating the tag to 12 bytes
var decrypted = one_gcm.Decrypt(ciphertext, truncated_tag12); // this is successful

NIST SP 800-38D說：

標籤的比特長度，表示為 t，是一個安全參數，如附錄 B 中所討論的。通常，t 可以是以下五個值中的任何一個：128、120、112、104 或 96。對於某些應用， t 可以是 64 或 32；附錄 C 給出了使用這兩個標籤長度的指南，包括在這些情況下對輸入數據長度和密鑰壽命的要求。

實現不應支持與前一段中的七個選項不同的 t 值。實現可能會將其支持限制為這些值之一。支持的選項中的單個固定 t 值應與每個鍵相關聯。

因此，標籤顯然不必是 128 位，儘管它應該是. 但是，我採用“單個固定值”表示您不應該對相同的鍵使用不同的標籤長度。這似乎是一種合乎邏輯的方法，因為否則您會降低安全性。例如，ChaCha20-Poly1305的RFC防止標籤截斷。

因此，你不應該做你正在做的事情，但我猜這個論點是由應用程序來強制執行這一點，而不是加密庫，如果他們想要支持多個標籤長度。

GCM 規範（NIST SP 800-38D）是否需要為 GCM 算法的實例（通常固定特定的 GCM 密鑰）固定標籤大小？

是的。

---

標籤長度噸 $ t $ 被認為是NIST SP 800-38D 第 7 節的先決條件。

它確實在 NIST SP 800-38D 第 7 節的頂部說：

然而，一些先決條件也可以被視為（變化的）輸入。

但在那之後，它明確提到，作為 7.1（GCM 加密）和 7.2（GCM 解密）的先決條件：

• 支持的標籤長度 t與密鑰關聯。

在我看來，這直接回答了你的問題。

---

GCM 的安全性很大程度上取決於標籤的大小，應考慮 NIST SP 800-38D 中短標籤長度的安全性考慮。NIST SP 800-38D 附錄的 B 和 C 部分都是關於身份驗證和使用小標籤大小的。

請注意，您不能完全相信標籤大小由標籤本身驗證，即作為附加驗證數據的一部分；如果構造易受攻擊，則攻擊者可以為包含標籤大小的消息創建一個小的有效標籤。

通常，您必須為標籤使用靜態大小噸 $ t $ 或者您需要事先協商標籤長度。

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