這個算法對於小型無線電資訊是否足夠好？
這個問題與：
如何實現 6/14 位無線電消息的安全性 - 真實性/機密性/完整性？
我正在尋找一條消息，即監聽無線電通信的攻擊者需要至少 2 週才能破解它。
我提出了這個解決方案：
- 1 字節標頭
- 3 字節 UMAC
- 4 字節 Nonce（遞增數）
- 8字節數據（用TEA加密）
每一方都有自己的 UMAC 和 TEA 密鑰，對方已經知道了。
我想使用具有大約 30 行 C 程式碼的wiki umac 實現和具有 10 行加密和解密的wiki TEA 實現。小程式碼對我的微型微控制器記憶體/快閃記憶體大小非常有用。
那麼，是否足以滿足我的要求？是否可以通過對未加密數據實施 umac 然後完全加密 umac+nonce+data 來進一步減小消息大小？
編輯- 關於創建消息的說明：
使用 TEA 密鑰計算 8 字節數據的 TEA 加密。
使用 umac 密鑰和 nonce 計算先前加密數據的 UMAC。
鍵不變。
這個問題，甚至補充了三個 有用的 評論，讓我擔心所設想的系統的安全性，原因有幾個（從最嚴重到最不嚴重）
- 在問題中被視為參考的C 程式碼中的UMAC 插圖僅對於單獨使用其密鑰是安全的。實際的 UMAC需要一個分組密碼，這在問題中沒有說明，而且它的程式碼要大得多。雖然該分組密碼可以是 TEA，但它不能是與用於加密的密鑰相同的 TEA（這至少會使 UMAC 的安全參數無效，並且可能容易受到攻擊）。
- 沒有說明當 UMAC 檢查失敗時接收設備會做什麼。如果它允許其他檢查，包括另一個 nounce，3 字節 MAC 似乎還不夠好：偽造需要平均 $ 2^{23} $ 嘗試（如果 nounce 被迫更改，則為兩倍），並且每秒 100 次，不到一天。另一方面，如果接收設備在 UMAC 檢查失敗時停止執行，則存在可靠性問題。速率限制很難做到正確，尤其是要使其抵抗拒絕服務和/或隨機功率損失。
- UMAC 檢查的一個簡單的逐字節實現可能非常容易受到定時攻擊（將平均嘗試次數減少到大約 $ 3\cdot2^7 $ ).
- 在恆定時間內進行 UMAC 最終檢查的不太天真的實現仍然可能容易受到攻擊，因為 UMAC 需要乘法，而這在“微型微控制器”上遠非恆定時間。
由於有效負載非常小（14 位），因此有一個更簡單的解決方案，無需 UMAC（從而減少程式碼並刪除消息中的 3 個字節），可以解決上述大部分問題（特別是將預期的偽造嘗試次數增加到幾乎 $ 2^{49} $ 嘗試）。
這個想法是
發送者使用 TEA 和固定共享密鑰加密一個 64 位塊連接：
- 32 位隨機數/增量數
- 18 位為零
- 14 位有效載荷
消息（13 個字節而不是問題中的 16 個字節）是：
- 1 字節標頭
- 4 字節 Nonce（遞增數）
- 8 字節密碼（Nonce、零、使用 TEA 加密的有效負載）
接收方對密碼進行解密，檢查解密的 64 位結果是否以 Nonce（從消息中提取）和 18 位為零開始，否則認為消息無效。如果對 Nonce 進行檢查（例如，它是增量的），則該檢查僅針對有效消息進行。
只要：
TEA 的實現是恆定時間的（見註）
32 位隨機數
- 首先在恆定時間內檢查，例如使用單個 32 位比較，
- 或與 18 位一起在零和恆定時間內檢查。
當上述完整性檢查失敗時，對 14 位解密的有效載荷不執行任何與數據相關的時序。
TEA 密碼是完整的（就其立場而言）。
根據評論更新：Nonce 的 32 位確實計入完整性。論點：試圖偽造的對手可以：
重用以前在真實消息中使用的 64 位 TEA 密碼，然後可以
- 在該真實消息中使用 Nonce；該消息將通過加密檢查，但與原始消息相同，因此不被視為偽造（此外，Nonce 的重複可能允許拒絕消息，因為 Nonce 應該是增量的）
- 使用不同的 Nonce；該消息將被拒絕，因此不算作偽造。
使用以前的真實消息中從未使用過的 64 位 TEA 密碼；假設 TEA 分組密碼的安全性（並且假設可以有盡可能多的 $ 2^{32} $ 具有 32 位 Nonce 的真實消息），對手基本上沒有關於驗證者對該塊的解密結果的資訊。無論送出給驗證者的 Nonce 值是多少，驗證者都將執行 TEA 解密，然後進行包含 Nonce 位的比較，並且對手無法預測正確的 Nonce，除非通過嘗試（這至少是 Nonce 必須在恆定時間內檢查）。因此，對於給定的偽造機率，Nonce 的每一個額外位都會使驗證者的查詢數量增加一倍（因此是攻擊的持續時間）。
更新：如果header需要認證，將64-bit塊格式改為8-bit header，32-bit Nonce，10 bits at zero，14-bit message；除解密後的消息外，繼續檢查每一位；並在恆定時間內至少檢查 header+Nonce（對手可以改變的任何內容）。
注意：在實踐中，很難不小心使 TEA 不抵抗定時攻擊。這將需要以下兩行程式碼來展示時序相關性 wrt
v0v1k0k1k2ork3，這對於 32 位寄存器幾乎是不可能的，並且僅適用於較小的寄存器和不使用加法進位或循環進位的程式碼.v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3); v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);（我經常遇到用於 8 位 CPU 的 C 編譯器，它們生成的程式碼具有與數據相關的時序，用於向變數添加一個小常量或添加不同大小的變數；但從來沒有一個為添加相同的變數而這樣做的大小，就像在實踐中的情況一樣）。
注意：在實踐中，最困難的部分是在存在隨機功率損耗和/或 DoS 的情況下穩健地生成和檢查語音。EEPROM 或快閃記憶體中的寫入和擦除不是原子的，有時會失敗，並且偶爾會使儲存單元處於讀取值變化的狀態（隨溫度、電源電壓或隨機雜訊）。
先說好東西：
- 該方案是encrypt-then-authenticate。
- TEA 和 UMAC 都適用於手頭的任務，TEA 的弱點在這裡並不重要，儘管fgrieu 發現UMAC 的描述使用存在一些問題。
現在兩個問題：
首先，加密是確定性的。這主要是消息的隱私問題。特別是如果你發送一個 8 字節的消息，比如說
"ATTACK!\0"（用 C 表示法），然後在同一個密鑰下再次發送相同的消息，你將兩次得到相同的密文，並且對手可以例如推斷他們將受到攻擊很快。現在解決這個問題非常簡單，您可以簡單地使用CTR-Mode，即使用您已經擁有的隨機數並加密為 $ E_K(m)=\operatorname{TEA}(\text{Nonce}\parallel 0^{32})\oplus m $ 在哪裡 $ \parallel $ 表示串聯， $ \oplus $ 按位異或和 $ 0^{32} $ 32 個零值位。其次，標頭和消息長度未經過身份驗證。如果報頭實際上包含語義資訊，例如預期的接收者，則它也應該被饋送到 UMAC 以確保例如消息不會被傳遞給錯誤的接收者並被接受。另一個潛在的問題是消息長度沒有明確地輸入到 UMAC 中。這主要是一種縱深防禦措施，如果可變長度相關數據或可變長度密文出現在某個時刻，它會特別有用。