我想在我的一個C＃.NET應用程序中加入和解密文件。該方案很簡單：用戶A向用戶B發送AES256加密文件。明文密碼在不同的頻道（例如電話或其他）上交換。使用Rfc2898DeriveBytes從明文密碼創建安全密碼時鹽的重要性
根據我的理解，我應該使用Rfc2898DeriveBytes將用戶的明文密碼轉換爲使用大概10,000輪的更安全的密碼。 （見this article）。
我不明白鹽在我的場景中的作用。通常使用哈希密碼來防止字典攻擊。但在我的情況下，PBKDF2算法通過增加PBKDF2輪次所需的額外計算來彌補短或簡單猜測明文密碼的弱點。
如果我選擇一個隨機鹽，那麼接收者也需要知道鹽也是爲了正確解密。如果我使用恆定的鹽，那麼黑客可以輕鬆地對我的代碼進行逆向工程，並使用恆定的鹽來運行暴力攻擊（儘管由於PBKDF2迭代，它們會非常緩慢）。
從我的理解，我別無選擇，只能在我的場景中使用恆定的鹽，並執行一個很好的明文密碼規則來彌補恆鹽的弱點。我的假設是否正確？
在密碼散列（和密鑰派生）的情況下，鹽用於防止像彩虹表一樣的預計算攻擊。
請注意，對於每個密碼，鹽必須是不同且不可預知的（最好是隨機的）。還要注意，鹽不必是保密的 - 這就是密碼的用途。通過保持鹽的祕密，你無法獲得安全。
在你的情況下推薦的方法是每次文件加密時生成一個隨機鹽，並將鹽和密文一起傳輸。
是否有一個具體的原因，你的方式使用AES-256？由於額外的輪次，它比AES-128慢大約40％，並且它沒有提供實際的安全優勢（特別是在基於密碼的加密方面）。
同樣值得考慮的是使用像PGP這樣已經建立好的標準，而不是從密碼學原語構建自己的協議，因爲構建安全協議非常困難，即使專家並不總是正確。
你的假設是正確的。如果他們有權訪問密碼，他們也可以訪問salt。我見過的BCrypt實現將迭代次數，哈希和salt都放在同一個結果字符串中！
這個想法是：你的散列應該是安全的，即使迭代的鹽和數字已知。 （如果我們總能知道攻擊者所知道的鹽和迭代次數以及算法是未知的，那麼安全性就會變得更加容易！在攻擊者禮貌地拒絕閱讀我們的鹽之前，我們必須假設他們將訪問如果他們有幾臺超級計算機和幾百萬年的計算時間，那麼你是對的，他們可以蠻橫逼迫它。
AES應該有隨機IV（我假設他正在使用除ECB之外的其他一些不安全的模式）。 Salt正在阻止使用彩虹表從哈希中獲取密碼，但攻擊者無法在此方案中獲取此哈希，因爲它僅用作加密密鑰。 –
@MaciejS攻擊者可以預先計算來自普通密碼的大量密鑰，並且可以針對任意數量的消息使用該表，而無需進行進一步的工作。 – ntoskrnl
你是對的，應該用鹽來防止這種攻擊。 –