Random-Number-Generator
密鑰派生函式的種子/鹽輸入是否保密？
我正在實現一個安全協議，並且對於密鑰管理，提出了一個使用遠端設備上的密鑰派生功能的方案。因此，輸入種子以明文形式上傳到遠端設備。現在，如果兩個實體共享相同的主密鑰並從這些主密鑰和種子/鹽生成會話密鑰，它們將派生相同的會話密鑰。
現在我完全不明白的是，隨機種子應該使用加密安全的隨機生成器生成，但可以以明文形式上傳到遠端設備。真的嗎？那是因為從密碼分析的角度來看，使用確定性隨機種子會洩露有關萬能鑰匙的資訊嗎？由於這是論文的一部分，因此我將不勝感激任何有關此的文獻。
先感謝您
現在我完全不明白的是，隨機種子應該使用加密安全的隨機生成器生成，但可以以明文形式上傳到遠端設備。真的嗎？
是的。salt 用於確保您不會兩次生成相同的設備密鑰。然而，會話密鑰仍然依賴於主密鑰，因此攻擊者無法生成設備密鑰。
因此，設備密鑰將是唯一且安全的。隨機數生成器需要安全以確保唯一性。為此，您還需要為此提取一個相對較大的鹽（例如，128 位或 16 字節的完全唯一性或 64 位，以防您喜歡在邊緣播放）。
使用特定於設備的唯一標識符更為常見。然而，（足夠大）鹽的優點是您不需要狀態。您不能出於意外或其他原因將標識符用於兩個或更多設備。通常除了使用其他派生數據之外，還會使用鹽（如果有的話）。
那是因為從密碼分析的角度來看，使用確定性隨機種子會洩露有關萬能鑰匙的資訊嗎？
不，無論如何，KDF 都不應該洩露有關主密鑰的資訊。這就是為什麼 KDF 通常要麼建立在塊密碼（當然可以保護密鑰）上，要麼建立在單向雜湊函式 / HMAC 上。
筆記：
- 我會在這裡使用“鹽”這個詞而不是“種子”。如果在談論 KDF 時使用，種子通常是輸入種子或密鑰，而不是鹽或任何其他派生數據。
- HKDF RFC有一個很好的部分介紹了鹽的使用。
- 強烈建議（我什至會說是必需的）在派生後對設備密鑰進行身份驗證，否則攻擊者可能會扭曲鹽值或將其設置為恆定值；為此，在雙方已知的數據上生成一個 MAC 身份驗證標籤，並將其返回給伺服器，然後伺服器可以驗證數據。
- 通常需要多個鍵。除非這些密鑰依賴於額外的傳輸數據，否則您可以只使用一個密鑰來驗證設備；通常這是一個 MAC 密鑰，或者——甚至更好——一個單獨的密鑰。創建一組設備密鑰需要額外的密鑰派生數據，通常是 ASCII 標籤，例如
"MAC","ENC"和"AUTH"或數字00,01和02。