為什麼不將 MAC 放在固定位置並覆蓋 MAC-then-encrypt 的填充？
將 MtE 與已知安全 (CBC) 的模式一起使用的最大問題在於填充，在通過查看填充字節知道身份驗證在哪里之前，您無法檢索身份驗證。
相反，為什麼不將 MAC 放在最後一個塊的最後，並在 MAC 的計算中包含填充字節？在查看填充或消息中的任何其他內容之前驗證 MAC（當然，計算 MAC 除外）。
填充算法將簡單地有一個參數告訴它在填充後為 MAC 保留多少空間，如果使用 EtM，則為 0，如果使用 MtE，則為標籤保留空間。
然後在消息上處理 MAC 加上添加的填充，並將其儲存在保留區域中。是否有任何填充方案可以做到這一點？
您的計劃，讓我們稱之為 pad-MAC-encrypt，確實可以修復任何針對 MAC-pad-encrypt 的填充 oracle 攻擊。
不使用它的原因可能是最初定義 CBC 方案時不知道填充預言攻擊，現在已知它們*，*似乎沒有令人信服的 CBC 案例。無論如何，其他模式比 CBC 具有優勢（不需要不可預測的 IV，更容易並行化）。如果出於某種原因（例如向後兼容性）確實需要 CBC，則可以使用簡單且易於理解的 encrypt-then-MAC。
即，與其問為什麼不使用它，不如問與其他安全方案相比有什麼優勢。
最大的原因可能是只有 CBC 模式加密才需要填充。
您在這裡所做的是將用於機密性的密碼模式與身份驗證所需的 MAC 混合。通過這樣做，您將填充與解密分離：
- CBC-解密；
- 驗證認證標籤；
- 取消填充。
創建為單獨的模組可能不是問題，但它需要單獨的填充/取消填充機制。該填充機制還需要將認證標籤大小（MAC 大小）作為參數。這不是使用現有 API 可以輕鬆創建的東西。其中許多可能只包含具有 PKCS#7 兼容填充的 CBC，這意味著必須重構 API。
如果這是作為一個單獨的模組實現的，那麼您已經創建了一個經過身份驗證的密碼模式。那裡已經有很多了。然而，他們中的大多數使用 CTR 模式並通過密文進行身份驗證。CTR 根本不需要填充，所以問題一開始就不會出現。
在解密之前執行驗證的一個很好的理由是處理明文。解密後的文本可能必須直接處理，否則需要緩衝。在您的情況下，您還需要儲存填充字節，而進一步操作不需要這些。
因此，即使您的模式可能很安全，但與許多 AEAD（身份驗證）方案相比，它並不是很實用。有很多更容易實現的模式，CTR / 流密碼，其次是 MAC，是 AEAD 密碼中最流行的。