MAC 與密碼可以用三種方式結合，同時為明文加密與鑑別：

• encrypt-and-MAC（加密並 MAC）
• MAC-then-encrypt（先 MAC 再加密）
• encrypt-then-MAC（先加密再 MAC）

這三種組合的差別在於加密與產生鑑別標籤的順序。至於選用哪個 MAC 或密碼演算法則不重要——只要各自安全，且 MAC 與密碼使用相異的金鑰即可。

三種做法所耗的資源大致相同。以下看看哪一種最可能是最安全的。

encrypt-and-MAC#

encrypt-and-MAC 分別計算密文與 MAC 標籤。給定明文 P，寄件者計算：

C = E(K₁, P)          密文
T = MAC(K₂, P)        鑑別標籤，直接由明文產生

由於加密與鑑別兩個操作彼此獨立，它們可以先後或平行計算。

寄件者把 C 與 T 都傳給收件者。收件者收到後：

1. 解密 C 得到明文 P = D(K₁, C)。
2. 用解出的明文計算 MAC(K₂, P)，與收到的 T 比對。

若 C 或 T 任一被破壞，驗證就會失敗，訊息被判為無效。

為什麼它最弱#

至少在理論上，encrypt-and-MAC 是三者中最不安全的組合，因為即使是安全的 MAC 也可能洩漏關於 P 的資訊，讓 P 更容易被還原。

使用 MAC 的目的只是讓標籤不可偽造，而標籤不必然看起來隨機。因此即使 MAC 被認為安全，明文 P 的鑑別標籤 T 仍可能洩漏資訊。

（當然，若該 MAC 是一個偽隨機函式，標籤就不會洩漏任何關於 P 的東西。）

儘管相對較弱，encrypt-and-MAC 仍被許多系統支援，包括安全傳輸層協定 SSH——每個加密封包 C 後面跟著標籤 T = MAC(K, N ‖ P)，其中 N 是每送出一個封包就遞增的 32 位元序號，用來確保收到的封包以正確順序處理。

實務上，多虧使用了 HMAC-SHA-256 這類不會洩漏 P 資訊的強 MAC 演算法，encrypt-and-MAC 對 SSH 而言已證明夠好。

MAC-then-encrypt#

MAC-then-encrypt 先計算鑑別標籤，再把明文與標籤一起加密：

T = MAC(K₂, P)
C = E(K₁, P ‖ T)

寄件者只傳送 C（其中同時包含加密的明文與標籤）。收件者：

1. 解密 C 得到 P ‖ T = D(K₁, C)。
2. 直接從明文計算 MAC(K₂, P)，確認它等於收到的 T。

評價#

與 encrypt-and-MAC 一樣，收件者必須先解密 C 才能判斷是否收到被破壞的封包——這個過程把可能已被破壞的明文暴露給接收方。

不過 MAC-then-encrypt 比 encrypt-and-MAC 更安全，因為它把明文的鑑別標籤藏起來了，從而防止標籤洩漏關於明文的資訊。

TLS 協定多年來使用 MAC-then-encrypt，但 TLS 1.3 已改用鑑別式密碼取代它（見第 13 章）。

encrypt-then-MAC#

encrypt-then-MAC 送兩個值給收件者：

C = E(K₁, P)          密文
T = MAC(K₂, C)        由密文產生的標籤

收件者用 MAC(K₂, C) 計算標籤，驗證它等於收到的 T。若相等，才計算 P = D(K₁, C)；若不相等，直接丟棄密文。

為什麼它最強#

• 收件者只需要計算 MAC 就能偵測被破壞的訊息，不必解密已損壞的密文。
• 攻擊者除非攻破 MAC，否則無法把 C 與 T 對送給收件者去解密，這讓攻擊者更難把惡意資料傳給收件方。

這些特性讓 encrypt-then-MAC 比另外兩種做法都更強。

這也是廣泛使用的 IPSec 安全通訊協定套組採用它來保護封包（例如在 VPN 隧道中）的原因之一。

那為什麼 SSH 與 TLS 不用 encrypt-then-MAC？

簡單的答案是：SSH 與 TLS 創立時，其他做法看起來已經夠用——不是因為理論弱點不存在，而是因為理論弱點不必然會變成實際漏洞。