為什麼 MAC 使用 nonce+message+hash(nonce+message+identifier) 不是標準？
鑑於我們知道
nonce + message + hash(nonce + message + mac-key)所有內部加密都可以檢測攻擊者是否更改了消息的任何位（本質上是將可延展密碼轉換為不可延展密碼），為什麼他們仍然說先加密然後 MAC？此外，添加像對稱密碼那樣分成對的mac-key是否不會通過證明其他不受密碼攻擊的材料是已知的（假設有足夠的長度）來驗證攻擊者的身份？
當然，如果我們完全不對稱，我們會先簽名然後加密，但這不是要問的問題。
編輯：我更喜歡的加密算法都具有沒有無效輸入的屬性，因為任何密文+任何密鑰->一些“明文”，通常是垃圾。不會存在對算法的攻擊會導致實現崩潰。
編輯：好的，由於大多數散列函式不合適，我得到關於 HMAC 不是散列（a + b）的部分。我更喜歡將散列函式替換為不適合任何用途，一旦它達到不適合該用途的狀態，但無論如何。我不明白為什麼我們關心密文是否已被更改。由於倒帶流，我的東西的設置方式在嘗試解密之前對 MAC 並不快。
如果存在加密方案，則存在這樣的加密方案，使得
人們可以輕鬆地修改單個密文，以便是否修改解密
結果以可預測且有用的方式取決於明文消息是什麼，例如：
修改後的加密操作輸出與原始加密算法的輸出連接的零。 $ : $ 如果輸入密文為空，則修改後的解密操作給出與原始解密算法相同的輸出。 $ : $ 如果輸入密文以零開頭，則修改後的解密操作在給定密文 的其餘部分時輸出原始解密算法的輸出。
如果輸入密文以 1 開頭，後跟自然數 的無前綴編碼
， 則修改後的解密操作將原始解密算法的輸出應用於密文的其餘部分，並附加許多（可能為零）零使其
比自然數長，使
$$ natural number $$-th 位一個，並輸出結果。
否則，修改後的解密操作在給定空密文時
輸出原始 解密算法的輸出。 如果 MAC-then-encrypt 與允許此類密文修改的加密方案一起使用，這種修改
以可預測和有用的方式依賴於明文的實際消息組件，
那么生成的方案仍然是可延展的。