Encrypt+HMAC 比 AEAD 強嗎？
我遇到的一些文章似乎暗示使用正常加密和 MAC 可能比使用較新的 AEAD（即：AES/GCM）模式更好。
https://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
https://blog.cryptographyengineering.com/2011/12/matt-green-smackdown-watch-are-aead.html
我的問題是：
AEAD 是否更有可能失敗（受到選擇的明文攻擊，而 HMAC 更安全地保護加密部分），如果是這樣，它是否以更災難性的方式失敗？
假設您已經安全地生成了 HMAC 和加密密鑰，那麼 Encrypt+HMAC 是否更安全？
這是我傾向於不同意 Colin Percival 的一點。
當且僅當您可以正確使用時，您應該使用 Encrypt-then-HMAC 。最大的缺陷是使用短路字元串比較與恆定時間字元串比較。鑑於前者，人們可以使用定時攻擊來為任意密文偽造有效的 HMAC。使用像 CBC 這樣的加密模式，這可以用來讀取加密消息的內容。其他陷阱包括意外實施 Encrypt-and-MAC 或 MAC-then-encrypt，它們在歷史上存在與其構造相關的漏洞。
另一方面，EAX 和 GCM 模式透明地提供了這個特性。對於針對專用 AEAD 模式的潛在側通道攻擊存在一些擔憂，並且還有可能將未經身份驗證的數據包傳遞給您的解密算法的概念問題。當然，您必須獲得正確的唯一 IV 等詳細資訊，但您也對 Encrypt-then-MAC 有此要求。
也就是說，EAX 和 GCM 實現中的潛在缺陷可以通過相關庫的更新檔一次為許多人修復。非密碼學家天真地比較 HMAC 的缺陷很普遍，甚至像Google的 KeyCzar 這樣的高調項目也犯了這個簡單的錯誤。如果您絕對知道自己在做什麼，那麼 Encrypt-then-HMAC 是一種可證明的安全構造。如果你不知道自己在做什麼，可能會發現像 EAX 或 GCM 這樣的東西有弱點，但它們肯定比自己實現一些東西要好。
編輯：我可能讓 Encrypt-then-HMAC 聽起來比實際上更容易。Encrypt-then-HMAC 的另一個主要缺陷是沒有 HMACing 足夠的資訊，或者沒有正確 HMACing 資訊。HMAC必須包括密文、附加認證數據和初始化向量。它可能還必須（也許其他人可以確認或否認這一點）包括一個描述符來辨識所使用的加密算法。要將這些欄位傳遞到 HMAC，您必須使用明確描述欄位的格式。最簡單的方法是在任何可變長度欄位（通常只是身份驗證數據和密文）之前添加一個 4 字節的 big-endian 長度，但對所有欄位執行此操作可能是個好主意。如果您不對所有這些資訊進行 HMAC，則攻擊者可以修改任何未包含的數據。如果您不明確地對它們進行 HMAC，則攻擊者可以操縱消息邊界，這可能使他能夠進行漏洞利用。
編輯 2：我忘記了 Encrypt-then-HMAC 的另一個細節。希望您能看到要做到這一點是多麼困難。理想情況下，您永遠不應該跨安全上下文重複使用相同的密鑰。我不知道使用您的加密密鑰作為 HMAC 的密鑰會導致任何攻擊，但最佳做法是使用不同的密鑰進行加密和身份驗證。一種簡單的方法（假設 256 位加密算法和 256 位 HMAC）是使用“虛擬”512 位密鑰。前半部分用於加密，後半部分用於身份驗證。另一種方法是使用 256 位密鑰，但通過 HKDF 以 512 位輸出傳遞它；像以前一樣使用它：將其拆分為兩部分，一個用於加密，一個用於身份驗證。
編輯 3：幾個月前，我在安全 StackExchange 上提出了一個高度相關的問題。Thomas Pornin 的詳細回答可能會有所幫助。