HKDF隨機提取-加鹽還是不加鹽？
根據HKDF 論文，使用鹽有兩個目的：域分離和隨機性提取。
這個問題只是關於為了隨機提取而需要鹽的必要性。
HKDF文件指出：
一個鹽值（即，一個隨機但非秘密的密鑰）…… 對於獲得可以從具有足夠高熵的任意源中提取隨機性的通用提取器和 KDF 至關重要。
Randomness Extraction and Key Derivation論文（由HKDF 論文連結）指出：
此外，對單個（非鍵控）函式（如 SHA-1）的“整體”隨機性假設不適合隨機性提取的設置，因為沒有單個函式（即使是完全隨機的）可以從任意函式中提取接近均勻的分佈高熵輸入分佈。確實如此，因為一旦函式被固定（即使是純隨機值），那麼就會有高熵輸入分佈將映射到輸出的小子集. 因此，隨機性提取的可行方法是考慮由一組鍵索引的函式族（或集合）。當應用程序需要對輸入進行散列以提取隨機性時，則從該族中選擇一個隨機元素（即函式）並將該函式應用於給定的輸入。雖然可能有特定的輸入分佈與族中的特定函式產生不良互動，但一個好的隨機性提取族將使這個“壞事件”以非常小的機率發生。
最後一個問題是如何生成提取器使用的隨機已知密鑰。從技術上講，這並不難，因為各方可以生成適當的隨機性，但確切的細節取決於應用程序。例如，在前面討論的 DH 密鑰交換中，各方交換隨機選擇的明確值，然後將這些值組合起來生成單個密鑰*$$ salt $$*對於提取器系列（例如 HMAC-SHA1）。
HKDF文件指出：
默克爾-丹加德家族*$$ used in the design of many popular hash algorithms such as MD5, SHA-1 and SHA-2 $$*建立在隨機壓縮函式上並不是一個好的統計提取器……在任何最後一個輸入塊固定的分佈上，此類家族的輸出在統計上遠非均勻）
然後，它呼應了Randomness Extraction and Key Derivation論文中的觀點：
正如我們在前幾節中已經強調的那樣，通用提取器，即那些在任意高最小熵源上工作的提取器，必須通過隨機但不一定是秘密的密鑰（或“鹽”）進行隨機化。特別是，引理 2 之後的範例表明，對於每個確定性提取器，都有一個高熵源，其輸出遠非均勻。
與這些陳述相矛盾的是，我知道一個 ECDH 實現在沒有鹽的共享秘密 EC 組元素上使用 Keccak-256 散列，但這也許是合理的 A），因為選擇海綿構造散列可以減輕擔憂這會影響 Merkle-Damgard 家族雜湊，或 B），因為 EC 壓縮點表示足夠均勻隨機（與非 EC DH 中共享秘密的隨機性均勻性相比）。
什麼情況下需要鹽？（針對哪些類型的輸入密鑰材料，以及針對哪些類型的 HMAC-Hash 函式）。
這些論文是否已經過時了，通過對現代散列函式的性質進行更深入的研究，這些論文提出的關於使用鹽的擔憂是否在一定程度上得到了緩解？
術語在這裡很重要。加密鹽的主要目的是在重用期間保護密碼並避免雜湊預計算。所以是的，這提供了您的域分離。但是您的問題是關於從任意來源（包括設備）中提取隨機性。
- NIST 的 SP800 90B *“用於隨機位生成的熵源的建議”*沒有就必須使用哪種類型的提取器或配置提出具體建議。您可以按照第一篇論文中的建議使用 MD5。或者滾動你自己的奇異類型，只要你計算輸出熵的偏差 $ < 2^{-64} $ .
- 鹽可以是公共的，因此它可以被重用，因為它是已知的。請記住，您不是在保護密碼，而是從提供（誠然不統一）但總是隨機來源的熵源中提取。因此，輸入熵流使加鹽要求變得多餘。
- 我不接受將最終塊固定為 Merkle-Damgard 架構意味著需要加鹽和 HKDF。是的，它們證明了後續輸出的不一致性，但在我看來，這是一種攻擊場景。如果對手可以將一個全零塊輸入您的提取器，您需要更好地保護房間。在 I/O 熵計算（通常是 Left Over Hash 引理）中滿足了簡單的填充。你的論文實際上也說了這麼多，促進了計算不可區分性的論點。
- 商業 TRNG 不會專門隨機加鹽。無論如何，任何鹽都會在生產執行中重複使用。
- 從哲學上講，幾乎所有隨機提取器的初始化向量中都嵌入了鹽。查看 SHA2 實現中的大數字塊。或 Toeplitz 矩陣。
所以我同意kelalaka 對你的評論。不需要鹽。