Encryption
如何將密碼提供給密鑰派生函式？
假設我想加密數據，通過網路發送，然後在接收端解密。
我知道這樣做的優雅方法是使用對稱密鑰加密數據，並使用非對稱密鑰將對稱密鑰發送給接收者，以便他可以解密數據。
但我剛剛閱讀了另一種方法，即使用基於密碼的密鑰派生函式來計算雙方的密鑰。這樣，沒有交換密鑰。但這需要雙方在計算密鑰時使用相同的密碼，所以我想我必須在某個時候將密碼發送給接收者，以便他可以計算相同的密鑰並使用它來解密。
如果我的理解是正確的，那麼我看不到使用 PBKDF 的目標，因為我必須在某個時候發送一些東西。如果沒有，那我錯過了什麼？
KDF 更適合用於離線協議。第二種情況經常使用的是密鑰協商協議。據我所知，在雙方都需要先驗地知道密鑰的互動式環境中，沒有安全的方式使用 KDF。密鑰協商協議使得按需計算共享密鑰（加密/解密密鑰）成為可能——雙方可以將此類共享密鑰播種到加密安全 PRNG 中以實現前向安全。
您是對的：如果您想使用基於密碼的密鑰派生函式 (PBKDF) 發送消息，通常需要同步或以其他方式同步資訊。
這並不意味著在客戶端使用密碼，在伺服器端使用派生密鑰沒有優勢：
- 密碼不儲存在伺服器端，因此如果後台數據庫被盜，攻擊者可能無法獲知密碼；
- 密碼和密鑰都需要儲存在客戶端（並且密鑰不是那麼容易記住），因此在客戶端竊取設備可能不會導致任何違反協議的行為。
也就是說，PBKDF 通常不用於線上協議中發送消息。相反，可以使用基於密碼的密鑰協議或 PAKE來驗證客戶端並建立對稱密鑰。但是，PAKE 也需要設置階段。在 Augmented PAKE 中，伺服器不學習密碼，只學習用於驗證的派生值。
最後，基於密碼的加密沒有什麼不對稱的。密碼是秘密；該秘密或派生值需要與身份驗證方共享。
請注意，客戶端應用程序通常也來自與伺服器相同的組織。這意味著客戶端將不得不在某個時候依賴組織的安全性——無論使用哪種加密協議。只能盡可能地緩解這個問題。