Encryption
我們應該先 MAC-then-encrypt 還是先加密-then-MAC？
大多數情況下，當某些數據必須加密時，還必須使用MAC進行保護，因為加密只能防止被動攻擊者。有一些漂亮的加密模式包括 MAC（EAX，GCM …），但假設我們正在做舊式加密，所以我們有一個獨立的加密方法（例如 AES 與 CBC 連結和 PKCS#5 填充）和一個獨立的 MAC（例如帶有 SHA-256 的HMAC ）。我們應該如何組裝加密和 MAC？
- MAC-then-Encrypt：計算明文上的 MAC，將其附加到數據中，然後加密整個？（這就是TLS所做的）
- Encrypt-and-MAC：計算明文上的 MAC，加密明文，然後將 MAC 附加到密文的末尾？（這就是 SSH 所做的）
- Encrypt-then-MAC：加密明文，然後在密文上計算 MAC，並將其附加到密文中？（在這種情況下，我們不會忘記將初始化向量 (IV) 和加密方法標識符包含在 MAC 化數據中。）
前兩個選項通常稱為“MAC-then-encrypt”，而第三個選項是“encrypt-then-MAC”。贊成或反對的論據是什麼？
我假設你實際上比我更了解這一切。無論如何，本文巧妙地總結了所有這些方法，以及它們提供或不提供的安全級別。據我所知，我將用英語而不是數學符號來解釋它。
加密然後 MAC：
- 提供密文的完整性。假設 MAC 共享密鑰沒有被洩露，我們應該能夠推斷給定的密文是真實的還是偽造的；例如，在公鑰密碼學中，任何人都可以向您發送消息。EtM 確保您只閱讀有效消息。
- 明文完整性。
- 如果密碼方案是可延展的，我們不需要那麼擔心，因為 MAC 會過濾掉這個無效的密文。
- MAC 不提供任何關於明文的資訊，因為假設密碼的輸出是隨機的，MAC 也是如此。換句話說，我們沒有將任何結構從明文帶入 MAC。
MAC然後加密：
- 不提供密文的任何完整性，因為在解密消息之前我們無法知道它是真實的還是欺騙的。
- 明文完整性。
- 如果密碼方案具有延展性，則可以將消息更改為有效並具有有效的 MAC。當然，這是理論上的觀點，因為實際上 MAC 機密應該提供保護。
- 在這裡，MAC 也不能提供任何關於明文的資訊，因為它是加密的。
加密和 MAC：
- 密文再次沒有完整性，因為 MAC 是針對明文獲取的。這為對密碼的一些選擇密文攻擊打開了大門，如破解和可證明地修復 SSH 身份驗證加密方案的第 4 節所示：Encode-then-Encrypt-and-MAC 範例的案例研究。
- 可以驗證明文的完整性
- 如果密碼方案是可塑的，密文的內容很可能會被改變，但在解密時，我們應該發現明文是無效的。當然，任何可以在解密過程中被利用的實現錯誤都已經存在。
- 可能會在 MAC 中顯示有關明文的資訊。當然是理論上的，但不太理想。如果明文消息重複，並且 MACed 數據不包含計數器，則會發生這種情況（它在 SSH 2 協議中包含，但僅作為 32 位計數器，因此您應該注意在溢出之前重新輸入密鑰）。
簡而言之，Encrypt-then-MAC 是最理想的方案。任何對密文的修改如果沒有有效的 MAC 都可以在解密之前過濾掉，從而防止對實現的任何攻擊。MAC 也不能用於推斷有關明文的任何內容。MAC-then-Encrypt 和 Encrypt-and-MAC 都提供不同級別的安全性，但不是 Encrypt-then-MAC 提供的完整集合。