HMAC-SHA3 是否應該優於 H(C(k,M))？
如果我理解正確，SHA-3 (Keccak) 比 SHA-2 更能抵抗攻擊。如果我理解正確的話，這將使使用 SHA-3 和比 HMAC 更簡單的方案成為可能。
是否還有理由將 HMAC 結構與 SHA-3 一起使用？簡單地使用會更好嗎 $ H(C(k, M)) $ 在哪裡 $ H $ 只是 SHA-3 和 $ C $ 是創建密鑰的規範表示（編碼）的函式 $ k $ 和消息 $ M $ 把它們分開？
當然，我認為 HMAC-SHA3 無論如何都會在大多數協議中使用，因為 SHA-3 是作為 SHA-2 的替代品而創建的。但是是否有任何與安全相關的理由來使用 HMAC-SHA3 而不是（甚至）更簡單的方案？
與 KMAC 結構相比，HMAC 沒有提供明顯的安全改進，這對於基於 Keccak 的功能是最佳的。HMAC 旨在為Merkle-Damgård類型的雜湊函式創建一個秘密初始化向量或 IV，KMAC 對基於海綿的雜湊函式執行相同的操作，但效率更高。HMAC還需要處理長度擴展屬性
KMAC 將密鑰擴展到塊大小並將其添加到消息中。我相信這將被標準化（如果尚未標準化）作為 SHA-3 的預設 MAC 結構。因為它將密鑰擴展到塊大小，所以在消息吸收之前對密鑰執行 F 次迭代，從而創建密鑰狀態。
這是在 Keccak 設計階段討論的基本海綿 MAC 構造，以及稍後對Keccak 和 SHA-3的討論。需要某種編碼或填充來有效地分離不同大小的鍵，但這在那些文件中沒有討論；這 $ C $ 您提到的功能將執行這種分離。在FIPS 202 發布後不久的2014 年 8 月 SHA-3研討會上討論的KMAC 使用“keypack”功能填充密鑰並將密鑰塊的字節長度編碼為 8 位值，使用最少 9超出密鑰長度的附加位： $ \operatorname{Keypack}(K, l) = \operatorname{enc}(l /8) | K | 1 0 ^{l-\operatorname{len}(K)-9} $ 在哪裡 $ l $ 是塊大小。
對於所有變體，SHA-3 的“塊大小”至少為 576 位，這意味著 512 位密鑰只需額外的一次迭代即可對狀態進行加密 $ f $ . 此外，由於沒有塊或位計數器，計算資源少但記憶體足夠的設備可以簡單地將鍵控狀態作為其預設狀態進行 MAC 計算，並且與普通散列相比不會受到性能影響。
**更新：**由於最初編寫了這個答案，NIST 發布了SP 800-185標準化 KMAC 和一些其他有用的 Keccak 派生結構。
