AES - CCM，為什麼不在裡面使用 CMAC 而不是 CBC-MAC？
當我了解到這基本上是 CBC-MAC 的改進和更強大的版本時，我正在閱讀 AES-CMAC，它能夠安全地擁有可變長度的消息。
AES-CCM 在計數器模式下使用 AES，因此將 AES 轉換為流密碼。因此，據我所知，它最終需要消息身份驗證以確保消息完整性。這裡它使用CBC-MAC。但是如果 CMAC 更健壯，為什麼不直接使用這個呢？
我正在使用低功耗藍牙，該算法是 LE 安全連接加密的支柱。
感謝任何澄清。
AES - CCM，為什麼不在裡面使用 CMAC 而不是 CBC-MAC？
因此，在他們最初對 802.11i（WPA2）模式的建議中，Whiting、Housley 和 Fergueson 給出的唯一原因是：
這裡提出了計數器模式加密和CBC-MAC認證的組合。這些模式已經被使用和研究了很長時間，具有眾所周知的密碼特性，並且沒有已知的專利保留。它們提供了良好的安全性和性能，無論是在硬體還是軟體中實現。
所以他們可能主要是在尋找一種滿足他們當時特定需求的模式（沒有專利，相當快速和便宜，有安全證明），所以他們想出了這個相對簡單的結構。
此外，“CMAC”實際上是 OMAC1（2003 年的第一個定義（PDF） ），它基於基於 CBC-MAC的 XCBC（2000 年， PDF ）的 OMAC(2)（從 2002 年 12 月開始） 。因此，由於 CCM 規範是從 2002 年 1 月開始的，它顯然不能使用 OMAC / CMAC。此外，XCBC 在當時是眾所周知的，但存在需要 3 個密鑰的問題，這會將 CCM 的密鑰大小從 AES-128 的 128 位增加到至少 384 位，這可能是一個不受歡迎的結果。
但是如果 CMAC 更健壯，為什麼不直接使用這個呢？
所以我查看了規範，CMAC 實際上並不更健壯。CBC-MAC 本身是一個無前綴的 PRF（因此是一個 MAC）。因此，如果您不允許消息塊序列作為彼此的前綴，您將獲得一個安全的 MAC。
在 CCM 中克服這個弱點的方法是消息的長度被編碼到 CBC-MAC 的第一個輸入塊中，因此沒有兩個不同長度的消息可以作為彼此的前綴，因為初始塊總是不同的。CMAC 克服這個問題的方法是將一個常量秘密異或到最後一個輸入塊中，這樣攻擊者實際上並不知道 CMAC 的完整輸入，因此在不猜測密鑰相關常量的情況下找不到任何前綴。
如您所見，在安全方面，CCM 的 CBC-MAC 和 CMAC 在它們的屬性上是相當的。唯一的缺點是使用 CCM 您需要提前知道消息長度，這有時很不方便。
**獎勵：**我實際上認為消息長度的前置對於 CCM 來說是不必要的。這是因為 CCM 已經需要一個尊重隨機數的對手來保證安全（否則 CTR 組件會嚴重損壞），因此可以保證每個 CBC-MAC 呼叫的第一個塊是不同的，因此沒有兩個輸入可以是彼此的前綴。
另請注意，更流行的 GCM 至少與此 CCM 變體一樣嚴重，因為在這種情況下它會洩漏秘密身份驗證密鑰……