為什麼我們先加密然後mac，然後簽名然後加密？
這個問題是在我對我們應該先簽名然後加密還是先加密然後簽名的回答的評論中提出的。我認為將問題作為一個單獨的實體提出是最好的，所以：
應用 MAC的一般建議似乎是我們應該先加密，然後是 MAC。然而，關於簽名的一般建議似乎是截然相反的。
為什麼會這樣？這些想法不一樣嗎？如果是這樣，為什麼它們如此相反。
我自己已經回答了這個問題，但可以隨時改進這個答案。
好的。所以首先，讓我們消除加密然後簽名。為什麼這是個問題？簽名背後的想法是證明即使存在惡意行為者也有消息來自我。如果惡意行為者更改簽名下的密文，顯然這會使簽名按預期無效，但這只是一種可能的攻擊場景。另一個是攻擊者可以簡單地通過剝離現有簽名並添加自己的簽名來聲明消息的所有權 - 這很簡單，因為密文（而不是明文）已簽名。
因此，在這種情況下，依靠簽名來辨識收件人可能是致命的。DW 在他/她的回答中給出了一個例子。
另一種方法是先簽名然後加密。顯然，惡意對手無法在飛行中修改它，但簽名的目的再次是無可爭議地辨識發件人。惡意接收者可以轉發加密的簽名明文，並且看起來像是來自原始發件人，從而破壞了簽名的目標。
DW 提供了一種解決問題的方法。其他是簽名-加密-簽名、加密-簽名-加密等。
在 MAC 案例中，我們的目標是不同的。我們想知道密文是否已在網路上被修改，以及我們是否應該解密它（例如，防止創建一個預言機）或將其拒絕為已損壞。我們並沒有試圖辨識明文來自誰，只是它沒有在飛行中被修改。
所以你可能會問，好吧，如果攻擊者從密文中剝離 MAC 塊並用他們自己的替換它會發生什麼？由於我們已經交換了 MAC 密鑰並且我們假設這些密鑰仍然是安全的，因此接收者將辨識出無效的密文並拒絕它。
還值得回顧 Thomas 對一些附加項目的回答。具體來說，並非所有密碼學家都同意 encrypt-then-mac 是最理想的方法。
其次，Thomas 強調 MAC 提供針對選定密文攻擊的自動保護。DW 在他/她的回答中建議應該使用IND-CCA2密碼 - 也就是說，在自適應選擇密文攻擊下可證明是安全的。
雖然它並不完全準確，但我會說 MAC 和 IND-CCA2 擊敗所選密文攻擊的要求比比較 MAC 和簽名更接近平行，儘管乍一看 MAC 和簽名似乎在做同樣的事情。