將 PBKDF2 與 AES 集成時加鹽的目的是什麼？
我對密碼學有點陌生，我正試圖圍繞 PBKDF2 和 AES。作為免責聲明，這不會在實際應用程序中使用，我只是在本地測試東西作為一個有趣的項目。
現在我想做的是接受某人的密碼來加密消息，並在以後解密。
我正在做以下事情：
key = InputPassword() salt = RandomSalt() self.key = PBKDF2(key, salt, 16)然後我會用AES加密。在稍後的時間點，我會執行：
key = InputPassword() salt = RandomSalt() self.key = PBKDF2(key, salt, 16)再次。當然，我的鹽每次都會不同。問題似乎是當salt不同時，AES解密不起作用。因此，我是否應該在加密消息中包含鹽？例如發送類似：“message = message, salt=salt”？如果是這樣，鹽的用途是什麼，包括它會帶來什麼安全利益？
- 一個原因是為了減輕Oechslin工作 的Rainbow 表的影響。如果每個人都使用相同的鹽，可以建立一個彩虹表來破解每個人的密碼。甚至還有商業桌子出售（我不是在宣傳它們只是提供存在）。將鹽用於密鑰派生和密碼只會扼殺彩虹表的使用。如果存在多目標攻擊，彩虹表仍然很有用，尤其是對於分組密碼。
- 另一個不好的理由是僅通過一個密碼派生兩個不同的密鑰。例如，如果您想先使用 AES 加密，然後使用 HMAC，則需要兩個密鑰。通過使用兩種鹽，您可以獲得兩個密鑰。以下來自 Python 的 Crypto 模組。
$$ \operatorname{PBKDF2}(password, salt, count, dkLen, prf) $$
- **迭代（計數）**應大於 16，以使 hashcat 等密碼破解者的工作更加困難。65536或者根據使用者體驗，等待1秒以上可能不是很好的體驗，可以根據系統進行調整。
dkLen是預設的派生密鑰長度。它可以增加到 $ 2^{31}-1 $ 乘以散列函式的輸出大小。您可以增加它以使用一種鹽派生 AES 和 HMAC 密鑰，或者您可以使用具有兩種鹽的域分離。- 實際上，使用 PBDKF2 派生多個密鑰可能會有風險，一旦找到您的密碼，兩個密鑰就消失了。您可以使用 PBKDF2 生成密鑰，然後使用 KDF，如HKDF、rfc5869 $$ key = \operatorname{PBKDF2}(password, salt, 65536, dkLen, \operatorname{SHA256}) $$然後將密鑰與 HKF 一起用於具有上下文的不同上下文
$$ \operatorname{AES-KEY} = \operatorname{HKDF-Expand}(key, \text{“aes-key”}, 128) $$ $$ \operatorname{HMAC-KEY} = \operatorname{HKDF-Expand}(key, \text{“hmac-key”}, 256) $$ 在這種情況下，您不需要 HKDF 的提取機制，PBKDF2 就可以了。
- 如果您想向某人發送加密消息，則必鬚髮送生成的密鑰。對於此類問題，我們有更好的替代方案，例如 DHKE、libsodium crypto box或 RSA-KEM，它們基於公鑰密碼學。在 RSA-KEM 中，我們不使用 PBKDF2 來派生我們使用 KDF （如 KDF1 或 HDKF）的密鑰。
- PBKDF2 可用於保護登錄系統中的密碼或生成密鑰，如Veracypt磁碟加密實用程序。Veracypt 可以使用 PBKDF2 和RIPEMD160散列函式來派生密鑰加密密鑰來解密實際的加密密鑰。系統分區和其他容器的迭代次數為327661 。
655331為了再次訪問文件，您不僅需要使用密碼，還需要使用相同的參數；鹽和迭代計數。否則，您將無法訪問加密文件。Veracrypt 為您處理參數，它們不會保密！PBKDF2的新替代品是****Argon2 ，它是 2015 年密碼雜湊競賽的獲勝者。Argon2 可以在計算期間增加使用的記憶體，從而防止使用 GPU 進行大規模並行雜湊計算。Hashcat 可以計算
1173.1 kH/s對於PBKDF2-HMAC-SHA1和277.0 kH/s為了TrueCrypt PBKDF2-HMAC-RipeMD160 + XTS 512 bit基於Nvidia GTX 1080 hashcat 性能。*請注意，鹽不是秘密的，這裡只有您的密碼是秘密的。一旦您使用了正確的系統，那麼攻擊者的能力就是猜測您的密碼。因此，您必須使用強密碼。
- 不幸的是沒有 Argon2 可以比較
只需填寫上一個答案的一些細節
因此，我是否應該在加密消息中包含鹽？例如發送類似：“message = message, salt=salt”？
是的。salt 通常作為密文的一部分發送（例如，對於 OpenSSL，salt 是密文的前 8 個字節，用於基於密碼的加密）。
從理論上講，您也可以傳遞 kdf 參數（算法、計數、…），但不一定，這些可以修復。
如果是這樣，鹽的用途是什麼，包括它會帶來什麼安全利益？
正如已經回答的那樣 - salt 正在阻止使用彩虹表，並且 count 應該使字典搜尋不可行（可能會修復計數，因此創建密鑰需要 200-300 毫秒）