適用於哪些流行的操作模式（AES-GCM、AES-SIV、AES-GCM-SIV 等）？
我對開發能夠加密個人文件（最終將備份到雲）的軟體感興趣，並且一直在盡我所能遵循最佳實踐。
有多種形式的認證加密。（AES-GCM、AES-SIV、AES-GCM-SIV、CBC + HMAC、CTR + HMAC 等）但是，我很難確定哪種操作模式最適合我的案例. 泛泛而談：
我多次聽到“GCM 更難正確”的說法，因為與 nonce 重用相關的嚴重風險以及如果實施不當會導致側通道攻擊的傾向。雖然速度很快。
我知道 AES-SIV 至少被 Cryptomator 使用，這是一種類似於我正在嘗試開發的工具（根據他們的架構文件）。與 GCM 相比，AES-SIV 對 nonce 重用的懲罰較小，但可能沒有那麼快。
AES-GCM-SIV 試圖結合 GCM 和 SIV 的優點，既快速又對 nonce 重用有一定的抵抗力。
就 CBC + HMAC 而言，HMAC 在 GHASH 較弱的 128 位身份驗證標籤（由 GCM 使用）上利用 256 位身份驗證標籤。但是，CBC 不能像 GCM 那樣並行化。
CTR + HMAC可以以類似於 GCM 的方式並行化，但具有更強的身份驗證標籤。（同樣，HMAC 在 GHASH 的 128 位身份驗證標籤上使用 256 位身份驗證標籤）
儘管到目前為止我已經完成了閱讀，但我無法確定為什麼有人會選擇其中一種方法而不是另一種。歸根結底，我真的很想在雲中安全地保護我的文件，至少可以確保我加密的文件是真實的，並且沒有以任何方式被篡改或損壞。
我非常感謝任何可以為我指明正確方向的幫助。
我在 2018 年經歷了這個決策過程，最終選擇了一些非常保守的方法：使用 AES-256-CBC 和 HMAC-SHA-512 截斷為 256 位的 encrypt-then-MAC。
- 為什麼 SHA-512 優於 SHA-256？SHA-512 在 64 位機器上更快。（儘管最近的 AMD 處理器的 SHA-256 指令產生了 4 倍的加速：連結）。
- 為什麼選擇 AES-256 而不是 AES-128？ https://blog.1password.com/guess-why-were-moving-to-256-bit-aes-keys/
這對於我的案例來說已經足夠快了，但比許多替代方案要慢得多。AES 部分在 Intel 處理器上速度很快；散列最終在長消息上花費了大約 80% 的時間。
今天值得考慮的替代方案：
將 HMAC-SHA-512 替換為鍵控 BLAKE3（長消息速度快約 2.5 倍）。BLAKE3 本身很新，但有一些成熟的血統。
XChaCha20-Poly1305（長消息速度快約 2 倍）。隨機數最多可達 192 位，因此衝突的風險較小。
AES-GCM-SIV（長消息快約 5 倍）。似乎還沒有廣泛實施。
注意：這些性能估計模糊地基於“典型”2016 x86-64 處理器，該處理器具有專用的 AES 指令和一些通用 SIMD，例如 AVX。
在要求初始化向量不重複而不是隨機的密碼操作模式中，初始化向量稱為“nonce”（使用一次的數字）。
如果不能滿足模式的要求，就不要設計模式的實現。例如，如果一個模式依賴於初始化向量的唯一性，你必須盡最大努力確保唯一性。如果不能保證唯一性，請選擇其他沒有此要求的模式。否則，您可能會產生錯誤的安全感，並且您的應用程序最終可能最終會被用於忽略基本要求會導致失敗的場景。偷工減料最終導致失敗的例子有很多。例如，即使在 1940 年代不同發件人偶爾使用相同的一次性密碼本，攻擊者也可以解密消息. 雖然已經知道這種重用是一個嚴重的弱點，但人們可能認為偷工減料不會有後果，但事實確實如此。
因此，與其試圖找到“在某種程度上抵抗 nonce 重用”的模式，不如確保您的實現盡最大努力防止 nonce 重用，或者找到另一種不依賴於 nonce 的模式。確保 nonce 唯一性的問題是一個單獨討論的問題，但即使在您的場景中它實際上也是可以實現的。由於您的方案不允許定時攻擊或填充 oracle 攻擊，因此您可以將 AES-CBC 與任何 MAC 一起使用，例如帶有 SHA-2 的兩遍 HMAC 或帶有 SHA-3 的單遍 HMAC，例如 Encrypt-then- MAC (EtM)、加密和 MAC (E&M)、MAC-then-Encrypt (MtE)。如果您不需要更高的速度和並行性。否則，請使用 AES-GCM AEAD。但是，由於 CBC 模式為您提供了許多 HMAC 選項，我會遵循 KISS（保持簡單）原則，以減少創造性，