HMAC 加密密鑰應該有多長？
在這個問題的最佳答案中，回答者說“使用足夠長的鍵”。
我正在使用 SHA1-HMAC（可能切換到 SHA256-HMAC）算法來驗證發送給客戶端的 cookie，因為身份驗證令牌沒有被篡改。加密密鑰輪換，每 24 小時生成一個新密鑰。密鑰有效期為 3 天（即，有 3 個密鑰用於在任何時候為活動的 cookie 簽名），這意味著如果使用者 3 天未登錄，則身份驗證令牌無效。
我使用 32 個字元長的隨機字母數字字元串作為加密密鑰，這會被認為“足夠長”嗎？
散列和因此 HMAC不將字母數字字元作為輸入。您首先必須將文本“密鑰”轉換為位。我將“密鑰”放在引號中，因為 HMAC 的密鑰首先應該由位組成。
對 HMAC 的建議是（實際上）密鑰大小與輸出大小相同（以及基於 Merkle-Damgård 的雜湊的中間狀態）。現在讓我們假設密鑰中的字元是完全隨機的，並且使用了足夠大的字母表，比如 base 64。在這種情況下，您將擁有 32 * 6 = 192 位的隨機性。這大於所需的 160 位隨機性。
如果我們對每個字元編碼（如 ASCII 或 Windows-1252）使用一個字節，那麼您將得到 32 個字節。這比HMAC 中使用的
ipador小得多。這意味著在使用 or 對密鑰進行異或opad運算之前不需要額外的散列。只要您不使用需要超過 2 個字節進行編碼的字元，您甚至可以使用 UTF-16。任何超過 64 字節的內容都需要額外的雜湊計算。ipad``opad
低於密鑰的安全要求，取自RFC 2104 的第 3 節：HMAC: Keyed-Hashing for Message Authentication：
HMAC 的密鑰可以是任意長度（長於 B 字節的密鑰首先使用 H 進行散列）。但是，強烈建議不要小於 L 字節，因為它會降低函式的安全強度。超過 L 字節的密鑰是可以接受的，但額外的長度不會顯著增加功能強度。（如果密鑰的隨機性被認為很弱，則建議使用更長的密鑰。）
需要隨機選擇密鑰（或使用以隨機種子為種子的加密強偽隨機生成器），並定期刷新。（目前的攻擊並未指明密鑰更改的特定推薦頻率，因為這些攻擊實際上是不可行的。但是，定期密鑰刷新是一種基本的安全實踐，有助於防止功能和密鑰的潛在弱點，並限制暴露密鑰的損壞。 )
其中 H 當然是散列函式，B 是塊大小（SHA-1 為 64 字節），L 是中間/輸出大小（160 位或 20 字節）。
筆記：
- 如果您的密鑰的熵少一些，HMAC 不會以任何可怕的方式破壞；任何高於 128 位的東西都可能沒問題。
- 切換到 SHA-256 是一個好主意，即使從理論上講不需要替換 SHA-1。
