GCM解密和明文處理
使用GCM模式解密時，是否需要等待解密完成，（從而可以查看密文完整性是否OK）才開始處理明文輸出，或者是否可以開始處理明文文本並行沒有任何風險，關於選擇的密文和定時攻擊？（當然，我知道明文無論如何都必須被丟棄，如果密文的完整性看起來很糟糕）
TL；DR：不，您不應該在驗證標籤驗證之前處理 GCM 解密數據。
GCM 模式僅使用計數器（CTR 或 SIC）模式作為密碼。對於 12 字節的 IV，您只需通過添加字節來創建一個計數器
00000002並使用給定的密鑰開始解密。您可以在此處查看解密範例。創建一個從密文/明文中的不同偏移量開始的範例也很容易。當您在未經身份驗證的情況下處理解密數據時，您將面臨定時攻擊和明文預言機攻擊。您保留的任何取決於明文的狀態都可以被對手更改；攻擊者可以通過在相同偏移量處翻轉密文位，在 CTR 模式下為未經身份驗證的密文翻轉任何明文位。
您暴露的嚴重程度當然取決於所使用的明文處理。不過，我不會低估風險，即使是簡單的 Unicode (UTF-8) 字元解碼也可能洩漏資訊。攻擊者也有可能更改您的服務狀態，然後嘗試防止回滾（例如，通過關閉電源）。
您可以將解密的明文寫入臨時文件。然後，一旦身份驗證成功，您就可以將文件複製到最終目的地。這種處理可以在沒有太大風險的情況下執行，因為明文的內容不應該影響字節的處理。
通常，通過加密塊中的明文，驗證每個塊的身份驗證標籤來迴避這個問題。請注意，您需要某種協議來禁止對塊進行重新排序 - 您可以為此使用 IV。顯然，這也需要額外的空間來儲存每個塊的身份驗證標籤。
顯然，這些對協議的更改需要在加密期間執行；它不會影響現有的密文。
GCM 模式基本上是先加密後 MAC，其中 MAC 一般比 CTR 模式解密要快。因此，原則上可以在解密之前驗證 MAC。因此，原則上您可以驗證然後執行流解密，隨時隨地處理字節。為此，您需要專門的實現。
不幸的是，兩次傳遞相同的字節也會顯著減慢操作速度。一般來說，您最好嘗試加速 GCM 解密並記憶體結果。但是，您可以將這種複雜的方案用於記憶體不足的環境。