encrypt-then-MAC 如何緩解 padding oracle 攻擊？
讓我們假設 Alice 向 Bob 發送了一條消息。
據我所知，最流行的 MAC-then-encrypt 方案如下：Alice 用她的私鑰計算明文的 HMAC，然後用隨機的一次性對稱密鑰加密明文+MAC，即轉，由 Bob 的公鑰加密。
Padding oracle 攻擊允許 Eve 通過將 Alice 消息的修改版本發送給 Bob 並觀察修改版本是否會觸發填充錯誤或 MAC 驗證錯誤（當 Bob 將嘗試使用對稱密鑰解密加密消息時）來重構明文+MAC。
據說（例如，我們應該 MAC-then-encrypt 還是 encrypt-then-MAC？）切換到 encrypt-then-MAC 應該可以減少攻擊的可能性。在這種情況下，Alice 首先使用隨機的一次性對稱密鑰加密明文，然後由 Bob 的公鑰加密，然後發送加密消息和使用她的私鑰計算的 HMAC。
只要 Bob 接受來自所有人（包括 Eve）的消息，我看不出這如何防止填充預言機攻擊。Eve 仍然可以修改 Alice 的加密消息，使用 Eve 的私鑰計算 HMAC，並將其發送給 Bob。
在這種情況下，encrypt-then-HMAC 是否真的可以防止填充 oracle 攻擊？
填充oracle攻擊的最大問題是填充沒有非常仔細地實現（例如，如果使用EtM，您必須計算所有內容的MAC - 包括填充）。為了搶占對經典 Belare-Namprempre 論文的引用，請小心——他們的結果不適用於現代原語，因為現在我們以不同的方式證明安全性。請參閱 Eurocrypt 2014 的相關 Namprempre-Rogaway-Shrimpton 論文（在此處討論）。
填充預言機攻擊（假設）僅通過出現一個錯誤來緩解。現在這是非常標準的（因為一個明智的方案只會說“無效”而不是“填充錯誤”等），但是存在時序錯誤，可以讓您將填充錯誤與其他錯誤區分開來。
這個想法是在 Encrypt-then-HMAC 中，你總是在整個消息上計算 MAC。所以，讓 Bob 收到一條消息，他將把它解析為 $ (C||T) $ . 他會計算 $ HMAC(C)=^?=T $ . 他可以做到這一點而不關心如何 $ C $ 被放在一起，因此計算/檢查 MAC 不會洩露任何關於其中內容的資訊 $ C $ .
相反，假設我們有 MtE。然後他收到 $ C $ , 他認為 $ C=E(M||T) $ ， 和 $ T=HMAC(M) $ . 已解密 $ C $ 要得到 $ M′||T′ $ ，他現在必須弄清楚如何計算 MAC $ M′ $ . 這就是填充預言發生的地方，因為解密算法必須計算出應該有多少填充，從而洩露有關消息的資訊。