這種方法是否能夠防止填充 oracle 攻擊？
我知道防止填充oracle攻擊的方法是先加密然後mac。這是為了避免嘗試解密修改後的密文，並洩漏有關填充錯誤的資訊。
假設我們有一個經過簽名然後加密的內容。對於解密和簽名控制，此內容按以下方式處理：
- 解密內容而不告訴填充是否正確。
- 檢查解密內容上的簽名，如果不正確則返回錯誤，如果密文被修改，則應該是這種情況。
當想要避免 PO 攻擊（或任何其他選擇的密文攻擊）時，這種處理是否正確？
更準確地說，場景是：
- 內容使用非對稱密鑰（比如 RSA-PSS 簽名）進行簽名，
- 然後使用對稱算法（比如 AES-256-CBC）加密，使用隨機密鑰和隨機 IV，
- 對稱密鑰用另一個非對稱密鑰加密（比如 RSA-OAEP 加密），
- 然後將密文、加密的對稱密鑰和 IV 傳輸到接收程序。
- 接收方程序解密對稱密鑰，但不知道是否存在填充錯誤（OAEP 填充）
- 然後它使用（可能解密錯誤的）對稱密鑰解密密文，而不告訴是否存在填充錯誤（AES-256-CBC 填充）
- 然後，它檢查（可能解密嚴重，但大小合適）內容上的簽名，如果不正確則返回錯誤，拒絕接收到的內容。
您必須區分它在理論上可行和實際上可行。如果不進行全面檢查，我可以說這樣的方法是可以完全證明的。然而，實際上，幾乎不可能實現它。具體來說，您必須能夠區分由於對稱解密或簽名引起的錯誤。然而，這真的很難做到（實際上，幾乎不可能）。原因是您需要使其與時間無關。但是，如果您有填充錯誤，您甚至不知道該消息要驗證多長時間。對 TLS 的 Lucky13 攻擊之所以奏效，正是因為在某些情況下，編寫為時間無關的程式碼實際上並非如此。所以，我永遠不會做這樣的事情。
大量 SSL/TLS 的弱點是由於 MAC-then-encrypt 造成的，所以不要這樣做。GCM 今天在 Intel 處理器上是如此之快，以至於沒有理由不使用（只要確保你總是有不同的 nonce）。
接收方程序解密對稱密鑰而不告訴是否存在填充錯誤（OAEP 填充）
OAEP 填充的想法是，您可以檢查填充的正確性，而不會受到填充 Oracle 攻擊。這稱為“全有或全無”安全性。但是，您可以用以前包裝的對稱密鑰替換包裝的對稱密鑰。
然後它使用（可能解密錯誤的）對稱密鑰解密密文，而不告訴是否存在填充錯誤（AES-256-CBC 填充）
讓我們在這裡假設我們得到了一個先前包裝的對稱密鑰（因為錯誤的解密不應該是可能的）。
在這種情況下，填充可能會失敗，並且您很容易受到填充預言攻擊和可能的其他明文預言攻擊。這些很難避免。例如，要知道生成的純文字的大小，您仍然需要取消填充。現在填充可以放置在記憶體頁面邊界上，從而導致時間攻擊。
然後，它檢查（可能解密嚴重，但大小合適）內容上的簽名，如果不正確則返回錯誤，拒絕接收到的內容。
太少太遲。您仍然需要某種方法來確定消息和簽名的位置。這對於明文預言機攻擊來說已經足夠了。此外，如果有人要更改編碼方案，即使您以前沒有，您也會遇到麻煩。
正如 Yehuda 已經指出的那樣，幾乎沒有理由不使用經過身份驗證的密碼。你已經被警告過了。