Hmac
HMAC 中鍵填充的安全含義
我剛剛在課堂上學習了 HMAC。在 HMAC 散列函式中，密鑰是零填充的。
10並且1都將被轉換為相同的最終密鑰（例如1000）。這不是問題嗎？
通常，假定 MAC 算法的密鑰具有固定長度。（如果他們不這樣做，例如如果“密鑰”實際上是使用者提供的密碼，那麼無論如何您都應該通過合適的 KDF 執行它們。）當 HMAC 以這種方式使用時，沒有問題，因為填充過程無法映射相同輸出的兩個鍵。
（如果輸入鍵長於散列輸入塊長度，HMAC 指定它們在填充之前進行散列。在這種情況下，兩個鍵最終可能會被散列到相同的值，但實際上找到兩個這樣的等效鍵是很難找到雜湊函式的衝突。雜湊步驟確實將 HMAC 的有效密鑰空間大小減少到雜湊輸出長度；這只是一個問題，因為它使暴力密鑰恢復攻擊像單個暴力 MAC 偽造一樣容易.但是對於HMAC的正常應用，後者已經被認為是一個中斷，因此應該選擇雜湊輸出大小使其不可行。）
也就是說，正是由於其靈活性和強大的安全屬性（PRF-ness），HMAC 不僅用作通用 MAC，而且還用於其他目的，例如，特別是作為 PBKDF2 等基於密碼的 KDF 的組件。在此類用途中，如果不小心，HMAC 中的鍵填充（和散列）可能會導致問題：
- 對於長於散列輸入塊大小的鍵， $ k $ 和 $ H(k) $ 是等效的 HMAC 密鑰。這可能是一個問題，例如在一個設計粗心的應用程序中使用 $ H(k) $ 作為關鍵檢查值，從而將其洩露給攻擊者。
- 可以想像，一個懶惰的應用程序設計者可能會想利用 HMAC 靈活的密鑰長度，並簡單地通過向主密鑰附加各種後綴來從主密鑰派生輔助密鑰。在這種情況下，使用兩個不同長度的後綴（可能包括空後綴），其區別僅在於附加一個或多個空字節的較長後綴可能會產生等效的子鍵。
- 類似地，當 HMAC 用於密碼散列（例如，作為 PBKDF2 的一部分）時，兩個僅通過附加空字節不同的密碼將是等效的。當然，人們很少在密碼中使用（甚至允許）空字節，任何這樣做的人都可能會遇到更大的問題（例如，許多系統可能將使用者輸入儲存為以空字元結尾的字元串，從而有效地將其截斷為第一個空字節）。即使有人最終以某種方式最終使用了這樣一個等效的空填充密碼，其安全隱患也基本上與他們只是重複使用原始密碼相同。
在實踐中，所有這些問題都可以很容易地避免，只需了解它們而不是做一些愚蠢的事情，比如在密碼或子鍵後綴中使用空字節。HMAC 的密鑰填充方案的真正問題在於，它為粗心的密碼學家提供了一個微妙的陷阱，並且要求任何分析基於 HMAC 的方案的人都了解其內部結構。如果我們可以將 HMAC 視為理想的黑盒 PRF，那會更好更簡單，但可惜的是，由於可能存在等效密鑰，情況並非如此。