秘密消息能否在 MAC 標籤內安全傳輸？
發件人想要發送一個超級密碼 $ M $ 可以是“開始”、“停止”或“等待”。這實際上可以是任何程式碼字的選擇，並被用於任何用途，例如傳輸短命令或短狀態消息。程式碼列表也可以是特定的或與目前任務/目標相關的。然而，有限數量的程式碼字將使接收者的事情變得更快。我將嘗試解釋：
- 發件人和收件人都知道有效的程式碼列表 $ L $ 並共享一個隨機的 256 位密鑰 $ K $ 預先。此交換超出範圍。
- 讓 $ H $ 是具有 256 位輸出的安全散列函式，它也聲稱是格式為的安全 MAC $ H $ ( $ K $ | $ M $ ）。絞紗和可能的其他一些人符合這個標準。
- 發送者生成一個隨機的 256 位隨機數 $ N $ 每次傳輸。
- 發件人生成 MAC 標籤 $ T $ 通過計算 $ H $ ( $ K $ | $ N $ | $ M $ );
- 發件人發送 $ N $ | $ T $ 在明確的收件人。
接收者使用隨機數和密鑰嘗試程式碼列表中的每條消息，以嘗試與發送的 MAC 標記匹配，從而破譯消息：
function(K, L, N, T) { foreach M in L { if (T equals H(K | N | M)) { return M } } return invalid }您會注意到沒有發送單獨的 MAC 標籤來驗證隨機數和明文發送的 MAC 標籤。因為只有 3 個有效程式碼，所以接收者認為只有 3 個可能的 MAC 有效。這將攻擊者創建偽造的機會增加到 2^256 / 3 = 2^254 但這仍然是安全的。實際上，您可以擁有 1000 個程式碼字，並且安全性在 2^246 時仍然足夠。然而，當攻擊者發送虛假傳輸導致接收器的 MAC 驗證工作過多時，較短的程式碼列表可以更好地防止 DOS 類型的攻擊。對於更長的程式碼列表，也許是一個單獨的 MAC $ N $ 和 $ T $ 會解決這個問題。
據我所知，只有收件人應該知道真實的資訊。如果攻擊者對密鑰空間進行暴力破解（2^256 難度）或破壞散列函式，則可以。由於雜湊函式的抗衝突性，接收器幾乎不可能錯誤地解釋傳輸的程式碼，因為產生相同 MAC 標籤的有效程式碼字的可能性極小。
可以像這樣安全地傳輸、驗證和讀取秘密消息嗎？
該提案有兩個部分：使用密碼本和使用現有共享對稱密鑰發送簡短的機密和經過身份驗證的消息的方案。
密碼本可以單獨使用以提供一定程度的保密性，或者可以用於將特定的預先約定的含義賦予短消息，並結合用於發送這些短消息的任何方案。該答案的其餘部分側重於使用 MAC 發送此類短消息。
簡短回答：是的，該方案保留了消息的機密性和完整性。
安全散列函式的圖像前抗性確保了消息的機密性（與適當的強密鑰一起）。
使用隨機數可確保竊聽者無法判斷真實消息是否與任何先前消息相同。
MAC 的屬性可以防止偽造或操縱的消息被接受。
請注意，該系統不能防止重放攻擊或消息重新排序攻擊，即它不能用作通用安全通道。一旦攻擊者觀察到一條消息，他們就可以重播該消息，而收件人無法區分重播消息和新消息。如果接收者記錄所有有效的 nonce-message 對，他們可以檢測到重放，但不能檢測到亂序消息。
MAC 的這種使用不是建構安全消息傳遞系統的標準方法，因此不應用於生產系統。實際上，它具有非常大的消息擴展（256 位密文 + 每傳輸約 10 位數據 256 位隨機數 = 每 10 位消息約 500 位成本）。標準化替代方案的一個範例是 GCM，它更節省大小（96 位隨機數 + 最多 128 位標記 = 每個消息長度最多 224 位固定成本）並且支持非常長的消息。
是的，我不明白為什麼這個方案不安全。它在已知數據上使用 MAC - 防止重放。如果該數據是在本地接收或計算的，則無關緊要。
但是正如您已經向自己展示的那樣，您使用計算選項所需的位數降低了標籤的安全性。所以最後你也可以只 CTR 加密 $ m $ 消息的片段 $ M $ 並創建一個標籤值 $ t $ 那是 $ m $ 位更短。
協議中已經有一個隨機數（不必要地大）和共享密鑰，因此沒有什麼可以阻止在該方案中使用 AES-CTR。此方案的唯一缺點是您可能會失去一位空間（因為您將需要兩位來編碼具有 3 種可能性的值）。