對稱 MAC 收益
我有一個關於對稱消息認證碼 (MAC) 的問題。
假設 Bob 使用對稱密碼向 Alice 發送加密消息。據我了解：
(1) 他們的威脅模型可能或應該包括主動攻擊者向 Alice 發送惡意製作的密文以利用其解密程序中的漏洞的風險；
(2) Bob 和 Alice 可以通過確保 Bob MACs 他的密文來消除這種風險，並且 Alice 在解密之前檢查這些 MACs。（這當然假設 Bob 本人不會向 Alice 發送惡意製作的密文。）
這一切都正確嗎？
如果是這樣，這是我的問題。原則上，Alice 的程序在其 MAC 驗證程式碼中與在其解密程式碼中一樣可能存在可利用的漏洞。那麼，您不只是將惡意製作的密文的風險換成惡意製作的 MAC 的風險嗎？
也就是說，您是否可以說 MAC 化密文消除了解密方對惡意製作的密文的暴露，同時又不增加它使他們暴露於惡意製作的 MAC 的新風險（以前不相關）？
TIA
(1) 正確描述威脅模型。(2) 正確。
Alice 的程序很可能在其 MAC 驗證程式碼中存在可利用的漏洞，就像在其解密程式碼中一樣。那麼，您不只是將惡意製作的密文的風險換成惡意製作的 MAC 的風險嗎？
這種反對並不奏效，因為 MAC 試圖緩解的 Alice 解密程序中的錯誤的性質使得它們不太可能發生在 MAC 上。從廣義上講，它們是關於解密結果的資訊洩漏（旁通道）。比如，如果解密明文末尾的填充檢查通過；或者如果解密明文的開頭以一些預期的標題開頭。當現實生活中的程序使用作為黑盒提供的未經身份驗證的加密時，幾乎不可能避免來自解密黑盒之外的此類旁道。它們可能會導致或不會導致可利用的攻擊，但很難確定它們不會。
相比之下，MAC 沒有這樣的檢查。重新計算 MAC 並與提供的 MAC 進行比較。當談到最常見的側通道（時序）時，可能會出現的少數錯誤之一是可以確定（例如通過時序）MAC 匹配的字節或字數，但有一些已知的緩解措施：
- 恆時比較，簡單易行，100%解決問題。
- 使用 MAC 作為質詢/響應協議的一部分，本質上只有一次機會讓 MAC 正確，也可以 100% 解決該問題。
- 計數不正確的 MAC 並在幾次後發出警報。
- 對於 8 字節 MAC 和理想可利用的時序變化，攻擊者需要一個預期的 $ \approx2^{10} $ 嘗試查找 MAC；這會減慢他們的速度。
- 我們談論的是一個非常小的時間變化，通常是不可利用的，而不是一個通常更大的時間變化。結合上述情況，只能在一些罕見的情況下進行利用（我確實在 1990 年代遇到過實施不佳的智能卡）。
順便說一句：當涉及到其他側通道（例如通過功率分析恢復密鑰）時，是的，MAC 密鑰和加密密鑰恢復的可能性相當，特別是如果兩者都基於相同的加密原語。但至少這是恢復的兩個關鍵。
更新以下評論：
我在考慮諸如可利用的緩衝區溢出之類的錯誤。
接收路徑中可能存在緩衝區溢出，但這是不涉及加密的問題，必須獨立緩解。MAC 驗證本身不太可能導致緩衝區溢出，至少是越界寫入類型。檢查密文的 MAC 可以有效地防止由於解密到太小的緩衝區而導致的緩衝區溢出。
其他緩衝區溢出往往不在加密或 MAC 部分本身。它們位於使用解密明文的軟體中。這就是為什麼大多數需要加密的應用程序還需要確保解密的明文與加密的內容匹配的眾多原因之一，包括它的長度。MAC 是一種手段。該答案的第一部分重點介紹了為什麼經常建議對密文而不是明文進行 MAC 處理。
因此，總的來說，最好通過使用 MAC 來保護密文，即使這樣可以將格式錯誤的密文中的錯誤風險換成格式錯誤的 MAC 中的錯誤風險。
如果我們另外確保加密密鑰和 MAC 密鑰緊密聯繫在一起，例如從一個共同的密鑰派生，這是通常的做法，我會說最好對密文而不是明文進行 MAC 處理；並且可以在一定程度上確信解密中沒有錯誤（故障注入不是威脅，或者減輕了）。
但是在大多數情況下，關於 MAC-then-encrypt（MAC 是明文）或 encrypt-then-MAC（MAC 是密文）的爭論已經過時了：像 AES-GCM 這樣的經過身份驗證的加密現在已經廣泛使用，並且（如果安全的話）可以勝任以集成的方式，並以較低的計算成本。