AES-GCM 中針對流數據的延遲標籤檢查
目前有一個關於 .NET 的GitHub 討論不支持任何流數據的 AES-GCM，因為在標籤檢查之前發布解密數據會以某種方式揭示明文或 AES 密鑰（或一些此類未記錄的災難性故障）。兩個選擇之間有很多喋喋不休：
1. 允許 AES-GCM 用於流式數據
在解密數據時釋放數據，並在標籤檢查失敗時提醒呼叫者。最流行的 AEAD 結構（例如 AES-CBC-HMACSHA256）將加密和身份驗證作為兩個獨立的管道。因此，在解密期間至少可以暫時降級到僅隱私模式（即 AES-GCM => AES-CTR 模式），但在 GHASH 標籤簽出後升級回**隱私和身份驗證模式。**如果情況需要，呼叫者負責提醒使用者或緩衝數據。
2. 永久禁止所有流數據使用 AES-GCM
這從流式傳輸中消除了 AEAD（或特別是 AES-GCM），並將它們永久地限制為正常的僅隱私模式。或者強迫使用者自己進行身份驗證，這會重新審視最初的問題。或者更糟糕的是，使用者認為流媒體是一個死胡同，根本跳過任何加密。
問題：假設其他一切都正常（新密鑰、唯一 iv、長標籤、在 GCM 限制等下），是否允許使用 AES-GCM 進行流式傳輸（#1）好嗎？如果不是，那麼災難性的失敗是什麼？除了 AEAD，流媒體還有什麼選擇？如果 AES-GCM 的情況與廣義 AEAD 顯著不同，請也解決這個問題。
Windows ‘核心’ 加密層 (
bcrypt)、OpenSSL、Bouncy Castle (C#) 和 Java 加密體系結構都允許流式傳輸/繼續。此外，它的範圍是加密 API 本身，而不是高級協議。
您可以同時擁有 AES-GCM 和流媒體。但：
請勿對未經身份驗證的數據進行操作！
處理未經驗證的數據，如核廢料。
在技術上建構 AES-GCM 的 AES-CTR可以在驗證身份驗證標籤之前提供對數據的訪問這一事實是一個紅鯡魚。在驗證標籤之前允許訪問數據，並且需要單獨的 API 呼叫來驗證標籤，是一種載入的半自動腳踏槍。不要這樣做！
在驗證身份驗證標籤之前，不要允許任意長的消息！
任意長的消息會誘使您在驗證身份驗證標籤之前對消息的內容採取行動。
抵制誘惑！您所要做的就是將長消息分成有限大小的塊，這樣您甚至都不想這樣做。 您甚至可以為 AES-GCM 隨機數使用塊序列號，或者您可以使用像miscreant這樣的方案來為您處理塊。
霧霾是個壞消息！每個程序都是作為其輸入的程式語言的解釋器——有時該語言是圖靈完備的，或者即使不是，你仍然可以讓對手控制一台你從未想過以你從未想像過的方式存在的奇怪機器。密碼學讓您確保只有您嘗試與之對話的對等方才能對您的程序進行程式，而不是網際網路上的其他任何人。
如果阿肯色州州長執行了一系列偽造的行刑令，然後才核對了所有法官的簽名，人們對這個致命的監獄狀態會更加不安。不要讓你的程序成為那個州長！
請參閱有關 xsalsa20poly1305 的較早答案，以詳細說明與 AES-GCM 相同類型的密碼系統中有限大小塊的性能和拒絕服務影響。
使用（普通）AES-GCM 處理流數據（特別是允許接收者在經過身份驗證之前訪問明文）會破壞其安全保證。
是的，它會“工作”，因為如果攻擊者不篡改數據，數據將被正確傳輸。但是普通的舊 AES-CTR 也可以做到這一點，所以如果這就是你所關心的，那麼你不妨只使用 AES-CTR。或者甚至可能根本沒有加密。
允許使用像 GCM 這樣的經過身份驗證的加密模式，但實際上並不能保證消息的完整性，這只會給那些可能認為他們正在使用經過身份驗證的加密的使用者創建一個陷阱（因為他們碰巧使用了流 API 而不是非流API）他們實際上不是。 負責任地設計的加密 API 不應包含此類陷阱。
也就是說，正如 Squeamish Ossifrage 所指出的，可以使用 AES-GCM 安全地傳輸流數據（相對），只需將流拆分為離散的塊並分別驗證每個塊（使用適當的關聯數據來防止攻擊者將塊改組） . 如果您想提供基於 AES-GCM 的流式加密 API，那麼您應該這樣做。
請注意，我上面寫的所有內容同樣適用於任何其他非專門設計用於支持流式解密的經過身份驗證的加密模式，而不僅僅是 AES-GCM。這就是為什麼您沒有得到專門關於 AES-GCM 的答案的原因。就是說，讓我嘗試簡要地解決您的具體問題：
允許接收器訪問未經身份驗證的 AES-GCM 明文會損害 AES 密鑰嗎？
不是直接的。
但是，GCM 模式提供的完整性保護確實減少了攻擊面（通過防止涉及惡意修改的密文的攻擊），並且某些容易受到 AES 密鑰恢復攻擊的系統（由於其他漏洞部分）可能會被 GCM 模式提供的前線防禦保持安全。
例如，假設消息由流式影片組成，並且影片編解碼器（通常不被認為是安全關鍵部分）碰巧有一個緩衝區溢出漏洞，可以讓惡意製作的影片流觸發遠端程式碼執行，從而接管整個系統。接管系統後，攻擊者可以做任何事情，包括擷取加密密鑰。
由於未經身份驗證的 AES-CTR 加密允許攻擊者翻轉明文數據中的任意位，因此可以很容易地利用這種漏洞（假設攻擊者可以修改一些已知的明文）。然而，正確的 AES-GCM 加密可以保護影片流不被篡改，從而防止此類攻擊——但前提是在將任何明文傳遞給潛在易受攻擊的程式碼之前實際驗證了 GCM 身份驗證令牌。
許多適當的密碼系統設計都是關於最小化攻擊面並建立多層深度防禦，以便系統非關鍵部分的錯誤不會升級為實際的安全妥協。從這個意義上說，放棄 GCM 模式提供的消息完整性保護會通過消除一層防禦來削弱系統的整體安全性。
允許接收者訪問未經身份驗證的 AES-GCM 明文會損害明文本身嗎？
可能。同樣，這需要利用接收應用程序的非加密部分的行為，但它可能比密鑰恢復更容易。
例如，即使攻擊者實際上無法通過如上所述的篡改明文來觸發遠端程式碼執行，他們仍然可以通過翻轉明文中的任意位來將錯誤注入明文。通過監控接收方對此類錯誤的反應，他們可能能夠了解有關原始明文的資訊。正確使用 GCM 模式可以通過確保所有此類錯誤引發相同的響應來阻止這種攻擊：身份驗證失敗。
此外，如果攻擊者可以通過這種攻擊學習到某個密文和 IV 對應的明文，那麼他們也可以輕鬆解密具有相同 IV 的任何其他密文。當然，如果沒有適當地強制執行消息身份驗證，攻擊者可以自由選擇其偽造消息的 IV 為他們想要的任何東西。
作為一個最壞的例子，假設接收者在收到一個充滿錯誤的亂碼消息時，會發出一個錯誤，其中包含他們未能解析的亂碼數據。並假設攻擊者可以以某種方式觀察這些錯誤消息。然後，為了解密任何消息，攻擊者可以簡單地發送一條具有與目標消息相同的 IV 和任意（例如隨機或全零）密文的偽造消息。生成的明文幾乎肯定是垃圾，因此會觸發錯誤，從而允許攻擊者從錯誤消息中學習明文。然後，他們可以簡單地對明文和密文進行異或運算，以獲得該 IV 的密鑰流，並使用它來解密目標消息。
允許接收方訪問未經身份驗證的 AES-GCM 明文是否會使系統容易受到主動偽造攻擊？
是的。
有很多現實世界的攻擊場景，攻擊者對解密某些擷取的數據不感興趣，而只是想讓接收者根據他們選擇的一些偽造數據採取行動。而且，攻擊者通常可能不在乎是否在數據已經採取行動之後檢測到偽造。
在某些情況下，例如，如果接收者對未經驗證的數據所做的唯一事情是將其保存到臨時文件中，那麼當檢測到偽造時，可能會安全地將系統回滾到安全狀態。但通常情況並非如此，尤其是（如上所述）如果數據被饋送到可能具有潛在可利用漏洞的子系統。在這種情況下，一旦處理了惡意數據並且系統受到威脅，就無法撤消。
（我相信這就是 Squemish Ossifrage 對死刑的暗示。正如你不能只是說“哎呀，對不起，不是故意那樣做”並在一個人死後不殺他們，你也受感染的系統在被接管並且其所有機密都被洩露後無法解除妥協。您可能可以從頭開始重新安裝系統，但無法取回受感染的數據。）
如果您不打算在允許接收者訪問明文之前驗證身份驗證標籤，那麼首先使用 AES-GCM 有什麼意義嗎？
我知道你實際上並沒有這樣問，但我還是想回答這個問題。而且，在我看來，答案是明確的“不”。
使用 AES-GCM 而不是普通的舊 AES-CTR 的唯一優點是 GCM 提供消息完整性保護，從而阻止涉及消息偽造或篡改的主動攻擊。如果您不打算實際使用該保護，則不妨只使用 AES-CTR。至少那時你會知道你很脆弱。