MAC-then-Encrypt-then-MAC 方法的安全問題？
Encrypt-then-MAC 確實提供密文完整性，但不提供明文完整性。使用 MAC-then-Encrypt 則相反：明文完整性但沒有密文完整性。
我想到的是，使用兩者來解決*“部分缺失完整性”*問題可能是有意義的：
$$ \tt …\ MAC_2(ENCRYPT(plaintext,MAC_1(plaintext))) $$ 試圖研究這是否會引入更多問題而不是解決問題，但我找不到任何有用的論文來提供對這種方法的安全性分析。另外，我找不到任何討論相關方案的論文。
忽略潛在的速度影響並嚴格關注安全方面……有什麼明顯的原因我看不出為什麼不應該首先考慮這種方案？或者是否存在相關的參考文獻/論文，而我只是太不適合找到它們？（如果，我應該尋找什麼？）
編輯：
由於評論區表達了一些困惑——請注意，上面的 LaTeX 僅代表我正在談論的內容的可讀提示。它並不是要描述一個完整的公式（我認為由於前面的“ $ … $ ”，事實上沒有 $ key $ 在上面的 LaTeX 中）。更喜歡發布提示而不是完整公式的原因很簡單：完整的公式呈現/格式的可讀性要低得多，並且可能會使一些人感到困惑——我想阻止這一點。顯然，“對某些人來說不那麼令人困惑的東西，對其他人來說更令人困惑”。老實說，這是我沒有預料到的……我的錯。這是整個事情： $$ CypherText = IV || Encrypt(PlainText || MAC_1(PlainText, MacKey_1), IV, CipherKey) || \ MAC_2(IV || Encrypt(PlainText || MAC_1(PlainText, MacKey_1), IV, CipherKey), MacKey_2) $$ 甚至不要問如果我不使用
<sub>標籤會是什麼樣子……但是，這可能有助於理解我為什麼選擇發布提示。
在明文上使用 MAC 可能會洩漏有關明文的資訊（MAC 算法不一定能確保它們所應用的數據的機密性，儘管一些 MAC 算法（如 HMAC）看起來非常安全）。如果你想避免這個（理論上的）問題，那麼你應該在明文上加密MAC（即MAC-then-encrypt，而不是MAC-and-encrypt）。
只要你把內層MAC和明文一起加密，而內層MAC的密鑰與加密密鑰無關，那麼“顯然”這個內層MAC不會帶來額外的麻煩；內部 MAC 可以看作是一些明文冗餘。（事實上，您可以用一個簡單的散列函式替換內部 MAC。）
在 CPU 和數據大小方面，擁有兩種 MAC 算法似乎仍然很浪費。如果您要解決的問題是先加密後 MAC 設置中的解密密鑰錯誤，那麼更有效的解決方案是使用 KDF 從單個主密鑰派生加密密鑰和 MAC 密鑰。如果這樣做，那麼當 MAC 匹配時，您就知道您使用了正確的 MAC 密鑰，並且根據 KDF 的屬性，您還知道加密密鑰是正確的。碰巧的是，使用 KDF 從單一來源派生加密和 MAC 密鑰是一種非常常見的情況。所以在實踐中不會出現“缺乏明文完整性”的問題。這就是為什麼您提到的具有兩個 MAC 的構造似乎沒有得到太多研究。