簡單 AEAD 結構的安全性
介紹
我想與具有非常有限的程序程序記憶體（Arduino Uno - 32K）的小型 8 位設備進行安全通信。
我的目標是最小化程式碼大小和 RAM 使用量。我可以使用多種替代方案，但我有理由相信它們都將具有更大的程式碼大小和/或 RAM 使用率。有關詳細資訊，請參閱本文末尾。
我想出了一個非常簡單的帶有關聯數據的身份驗證加密 (AEAD) 結構，它使用 Speck 分組密碼。可以使用任何具有 128 位塊大小的塊密碼，但 Speck 在軟體中非常小。
Speck 用於身份驗證（CBC-MAC）和加密（CTR 模式）。在這兩種情況下，我都使用 128 位塊大小和 128 位密鑰大小。
高級概述
像正確的 AEAD 模式一樣，這種結構提供了兩種操作：
- 認證加密
- 認證解密
我想要一個類似於 NaCl 的介面，除了我包含額外的僅身份驗證數據，並且我使用兩個單獨的密鑰。因此，經過身份驗證的加密操作需要五個輸入：
- 認證密鑰 $ K_A $
- 加密密鑰 $ K_E $
- 隨機數 $ N $
- 純文字 $ P $
- 相關數據 $ A $
輸出是密文 $ C $ ，其中包含重建所需的所有內容 $ N $ , $ P $ 和 $ A $ . 如果你知道鑰匙，那就是。
認證解密的介面只需要這個密文 $ C $ 如果 MAC 驗證和所有其他完整性檢查成功，則返回 true；否則，它返回 false。它也返回 $ N $ , $ P $ 和 $ A $ .
認證加密
由於我追求極致的簡單性和較小的程式碼大小，因此我使這種結構變得非常不靈活和有限：
- 隨機數 $ N $ 必須是準確的 $ 7 $ 字節
- 附加數據 $ A $ 必須是準確的 $ 8 $ 字節
- 純文字 $ P $ 必須是的倍數 $ 16 $ 字節
字節 $ 0 $ 輸出的 $ C $ 是塊的數量 $ P $ ( $ \frac{length}{16} $ ）。這樣做的目的是使所有消息的集合在 CBC-MAC 中使用無前綴。它還將最大消息大小限制為 $ 256 \times 16 = 4 $ 千字節。
字節 $ 1-7 $ 的 $ C $ 是隨機數 $ N $ .
字節 $ 8-15 $ 的 $ C $ 是額外的認證數據 $ A $ .
接下來來了 $ P $ 在 CTR 模式下加密 $ K_E $ . 計數器塊的構造如下：
- $ 7 $ 字節隨機數 $ N $
- $ 8 $ 字節零
- $ 1 $ 字節計數器
最後，CBC-MAC 是通過加密所有先前的 $ C $ CBC模式下的數據，帶有認證密鑰 $ K_A $ 和零 IV（檢查點 2）。此加密的最後一個塊附加到 $ C $ .
我相信這個方案可以描述為Encrypt-then-MAC。
我有意避免使用計數器塊的所有字節來限制由單個密鑰加密的塊數。建議使用者不要使用鞋面 $ 4 $ 將加密限制為的隨機數位 $ 2^{60} $ 塊，這是 Ferguson 和 Schneier 在密碼學工程中推薦的 CTR 模式的最大值。
問題
- 假設隨機數 $ N $ 對於每條消息都是獨一無二的，這種結構是否符合機密性和真實性的標準概念？
- 將其稱為 AEAD 結構是否準確，或者另一個名稱更可取？
備擇方案
我可以使用 AVRNaCl，但他們驗證和解密密文的程序（
crypto_secretbox_open(我也可以將 CCM 或 EAX 與 AES 或 Speck 一起使用，但我相信這也會有更大的編譯程式碼，這是我的論點：
- 根據 JP Norair 的說法，EAX 需要的程式碼比 CCM 少。
- 有一組非常好的 Arduino 庫，稱為 ArduinoLibs，它包含一個加密庫，其中包括 Speck 和 EAX。我嘗試用 SpeckTiny 編譯 EAX，程式碼大小超過 4K。
- 如果 EAX 的程式碼大小比 CCM 小，那麼它不會小於 EAX 的 4K。當然，除非 EAX 程式碼經過優化，但我不是 AVR 組裝方面的專家，我仍然不確定它是否會接近本文中描述的構造大小。
- 即使只是直覺地，這篇文章中描述的構造也很簡單。這是幾行簡單的程式碼。我發現實現的唯一挑戰是進行恆定時間 MAC 驗證。CCM 和 EAX 都比這更複雜。
是的，這是安全的。 （我對此非常有信心的少數情況之一）。
以下是論據：
- 將安全（例如 SUF-CMA）MAC 與安全（例如 CPA-安全）加密方法結合在先加密後驗證中通常被證明是安全的。這在M. Bellare 和 C. Namprempre (PDF) 的“Authenticated Encryption: Relations between questions and analysis of the generic composition patterns”中得到了展示。同樣值得一讀的是Yehuda Lindell對連結問題的回答，它強調瞭如果可能的話**，您應該使用已建立的模式（如CCM或EAX）**，因為它們已經提供了完整的安全證明。
- 您正在使用帶有附加消息長度的 CBC-MAC ，假設底層塊密碼是 PRF （與它無法區分 $ 2^{n/2} $ 塊與 $ n $ 是塊大小（以位為單位）
- 使用的密碼是帶有斑點的 CTR 模式，如果塊密碼可以建模為 PRF，則它是可證明 (CPA) 安全的流密碼 $ 2^{n/2} $ 塊沒有任何問題，此外，您成功部署了針對底層模式下隨機數重用的對策，因此應該沒問題。