從同一個 DH 秘密 Z 派生多個密鑰有哪些風險？
NIST 在SP-800-56C (PDF)中推薦 Krawczyk 基於 HMAC 的密鑰派生函式 (HKDF )。例如，HKDF 應用於在 Diffie Hellman 密鑰建立後從共享秘密創建密鑰。
NIST 在同一文件中指出：
每次呼叫隨機性提取步驟都需要一個新計算的共享密鑰 $ Z $ ，並且在提取過程中使用此共享密鑰後，應立即將其歸零。
為什麼不建議從同一個密鑰派生多個密鑰 $ Z $ ，例如，為什麼不從同一個數據加密密鑰和認證密鑰導出 $ Z $ 使用不同的資訊字元串？如果我仍然這樣做，派生密鑰可能面臨哪些弱點？由於派生鍵顯然是相關的，這樣做只是不好的做法（沒有深入的解釋）嗎？Krawczyk 似乎認為從秘密中派生的多個推導是預期使用的（請參閱RFC 5869 中的第 3.2 節，我的解釋）。
從單個密鑰派生多個密鑰時，用良好的隨機鹽對 HKDF 進行加鹽是否會改變我的風險 $ Z $ ?
這取決於您如何使用 HKDF 派生多個密鑰。
背景：HKDF 由兩個階段組成：首先 HKDF-Extract 從隨機源計算中間值；然後可以使用 HKDF-Expand 從中間值生成一個或多個會話密鑰。
正確的方法是使用一次 HKDF-Extract，然後多次呼叫 HKDF-Expand，使用多個不同的資訊字元串。換句話說，要派生兩個會話密鑰，您需要呼叫 HKDF-Extract 一次和 HKDF-Expand 兩次。如果你這樣做，那麼這是一個非常好的做法——這正是 HKDF 的設計目的。
錯誤的方法是呼叫整個 HKDF 過程兩次，使用兩種不同的鹽。HKDF 的某些實現可能不會將這兩個階段分開，而只是將它們組合起來；如果您使用它，並執行了整個過程兩次（使用 HKDF-Extract 兩次和 HKDF-Expand 兩次），那麼這不是使用 HKDF 的預期方式。
如果您使用“正確”的方式，一切都很好，所以對於這個問題的其餘部分，我假設您在詢問“錯誤”的方式。關於這是否是一個好主意有兩個答案：“工程”答案和“有原則”的答案。
工程上的答案是，在實踐中，如果您使用兩個不同的資訊字元串生成兩個密鑰，我懷疑您可能會毫無問題地僥倖逃脫。如果我們將散列建模為隨機預言（誠然是一個非常強的“假設”），那麼我懷疑有可能證明您的建議是可以的。免責聲明：我沒有對此進行分析，我當然不會給你任何保證——如果你按照你的建議去做，密碼學家會搖擺手指說“tsk，tsk”，這是正確的。我懷疑你可能會僥倖逃脫（這不是你能犯的最嚴重的罪），但如果確實出了問題，密碼學家不會承擔責任——一切都在你身上。
更有原則的答案是，如果你按照你的建議去做，你就是在濫用 HKDF 原語。HKDF 僅適用於單個 $ Z $ 一次。它旨在將無法猜測的值變成看起來一致隨機的東西。它已針對該用途進行了分析。它不是為了從同一個密鑰中派生多個密鑰而設計的 $ Z $ : 它沒有針對這種案例進行分析，因為這不是它的設計目的。因此，如果您以非設計用途的方式使用 HKDF，您將放棄從公開分析中獲得的好處。
因此，鑑於以正確的方式使用 HKDF 非常容易，您可能應該這樣做。
您的建議——使用中間派生密鑰 $ K_{\mathit{DK}} $ 從單個輸入 $ Z $ 派生許多具有不同資訊字元串的輸出鍵——非常好。
您引用的摘錄是關於 HKDF-Extract 步驟，而不是 HKDF-Expand 步驟。它的意思是你不應該使用相同的 $ Z $ 為 HKDF-Extract 使用許多不同的鹽：與一種鹽一起使用，然後將其擦除。但是，該摘錄沒有說明具有不同資訊字元串的 HKDF-Expand。
RFC 5869在這一點上更清楚（強調）：
HKDF 遵循“extract-then-expand”範式，其中 KDF 在邏輯上由兩個模組組成。第一階段獲取輸入密鑰材料並從中“提取”一個固定長度的偽隨機密鑰 K。第二階段將密鑰 K“擴展”為幾個附加的偽隨機密鑰（KDF 的輸出）。
HKDF的標準安全性降低適用於可以自適應地查詢 HKDF-Expand 以獲取許多資訊字元串的對手，該定理由查詢數量參數化，因此您建議的用途完全符合 HKDF 的預期和研究用途。無論您是否使用鹽，這都適用。
您可以從 HKDF-Extract 和 HKDF-Expand 生成單個密鑰，並將其輸入另一個 PRF 以派生更多密鑰。但是，當 HKDF-Expand 已經這樣做時，這樣做會很愚蠢。