是否存在強制 mac-then-decrypt 的操作模式？
Alice 使用 AES-GCM 向 Bob 發送消息。Bob 是一名軟體開發人員，他的密碼學知識足夠危險。他想在收到數據後立即開始處理數據。他觀察到他可以忽略標籤，只解密 CTR 模式的密文。
在我能想到的每種模式下，都可以在不執行身份驗證部分的情況下解密消息。是否存在使嘗試跳過或推遲身份驗證變得不切實際的標准或命名操作模式？
似乎這樣的方案必然是兩次通過。如果第一遍始終是身份驗證，第二遍是解密，那很好。
對於這樣的加密方案如何工作，我有兩個（不完整的）想法。我包括他們的描述，因為它可能有助於更好地解釋上面提出的問題。
我最初的想法是首先使用未經身份驗證的算法和隨機 IV 加密明文。然後密文將被提供給某種 HMAC。HMAC 輸出的前 128 位將成為消息標籤。其餘位不會被發布，而是用作加密 IV 的調整。
（這可以防止接收者在沒有首先執行 MAC 算法的情況下解密消息，因為否則 IV 對接收者來說仍然是未知的。一個問題是 IV 沒有經過身份驗證。）
我的第二個想法是嘗試採用全有或全無變換，“一種無鍵的、可逆的、隨機變換，其特性是除非所有輸出都已知，否則很難反轉。”
有一種 AEAD 結構，例如以 CAESAR 候選AEZ為例，它分為兩個部分：
- 一種加密方案：“一個類似於傳統塊密碼的對象，除了明文的長度是任意且可變的，此外，還有一個調整”（第 1 頁）。
- 一種先編碼後加密模式，它使用固定數量的零（或其他一些替代方案）對明文的串聯進行加密。在解密時，真實性檢查驗證這些最終位是否被解密為零。
關鍵是在加密方案中，對密文（或分別為明文）的任何位的更改有 50% 的機會影響明文（或分別為密文）的每一位。因此，修改密文的嘗試會產生亂碼的明文，而這些亂碼的明文將可以安全地洩露。
我贊成之前關於 AEZ 的答案，因為我是 AEZ 的忠實粉絲，我認為你應該閱讀關於它的理論論文，因為它是了解很多關於對稱密碼學的重要論文。AEZ，這是一個可變大小的塊，可調整的密碼。它非常非常接近於全有或全無的轉換。對於塊的大小，塊密碼是全有或全無的。如果密文或密鑰中存在單個位錯誤，簡單的 AES 將為您提供完整的垃圾。一個全有或全無的系統可以被認為是一個具有任意大塊的分組密碼。
但你真正問題的真正答案是，即使這樣也不能解決你提到的問題。這個問題是程序員故意犯下的愚蠢行為。長期以來，那些重視性能而不是正確性的人一直是問題的根源。
如果您的範例中的 Bob 使用完美的全有或全無轉換並且沒有檢查錯誤，那將很糟糕。可以說，同樣糟糕。如果 Bob 不檢查其他返回碼，那就不好了。如果 Bob 任意愚蠢，那麼我們需要避免使用他的軟體，因為您可以修復錯誤但無法修復愚蠢。
一個好的 AEAD API 會做一些正確的事情，並向 Bob 返回一條錯誤消息（並且沒有數據）。在該 API 內部，它很可能會在進行過程中進行解密，以減少時序側通道。Bob 應該使用該 API。
好的，迷你咆哮結束。作為密碼學家，我們應該考慮讓程序員更容易做正確事情的事情。我很高興你正在考慮這一點，因為我們應該這樣做。看看 AEZ，因為我認為其中的原理就是你想要的，以及關於它的理論論文。一個大塊的、可調整的密碼幾乎正是你想要的。