在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史，其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章：「Encrypt-then-MAC」，當時 Colin Percival 寫的時候大家還是不能理解，但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD
SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題：對 128bits CBC mode system (像是 aes128-cbc)，任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161，論文是「Plaintext Recovery Attacks Against SSH」)
TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠，不過到了 2011 年時才被拿出來示範，也就是 BEAST attack。(CVE-2011-3389，在 ekoparty Security Conference 上的「表演」：「BEAST: Surprising crypto attack against HTTPS」，連結1、連結2)
OpenSSL 與 GnuTLS 所實作的 DTLS 在 2011 年也被炸到，其中 OpenSSL 是 100% plaintext recovery，GnuTLS 是 4%。(CVE-2012-0390，論文是「Plaintext-Recovery Attacks Against Datagram TLS」)
而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法，而且被證明 Provable security：Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。
附帶一提，其中 Provable security 這個詞，並非表示「可被證明是安全的」，在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低：以 Encrypt-then-MAC 的例子來說，如果 Encrypt 的部份用 DES，或是 MAC 用 CRC32，那麼 Encrypt-then-MAC 並不會提供更強的安全性...
總而言之，MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode)，而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式，有些有專利問題，有些演算法看起來就很複雜 (於是就容易出包)，其中 Encrypt-then-MAC 看起來是個還不錯的方案...
