目前設置中是否需要 PBKDF2？
我有一個密碼，它是加密數據庫的隨機字節。現在我正在使用https://gist.github.com/jbtule/4336842的加密方案。總而言之，我們使用一個密碼，為身份驗證密鑰和加密密鑰生成鹽，執行 PBKDF2 10,000 次迭代以生成密鑰，然後使用 AES 加密並使用 HMAC 進行身份驗證。然後將鹽儲存在密文旁邊。
我的問題是密鑰生成變得異常緩慢。加密和解密與其他繁重的 CPU 過程和許多查詢一起發生，因此對於任何給定過程都會發生許多解密。有時，我要解密的每個元素的密鑰生成步驟可能需要大約 5 秒。但是當我正在閱讀它時，我的案例似乎不需要密鑰派生函式，因為原始密碼是完全隨機的。
我正在考慮在 AES 和 HMAC 加密/解密之前使用單個密碼並將其與 crypt 和 auth salts 連接。我也可以簡單地將 PBKDF2 迭代降低到大約 10 次，這可能看起來很草率，但需要更改更少的程式碼和更少的測試。我在這裡缺少安全漏洞嗎？這些解決方案中的任何一個都會讓我受到攻擊、蠻力或其他方式的攻擊嗎？從我正在閱讀的有關密鑰生成的內容來看，我似乎不需要它，但是自製解決方案總是很糟糕，因此我在刪除我們擁有的任何安全性時非常謹慎。謝謝你的幫助。
每當 PBKDF2 用作具有大熵鍵的 KDF 時，它的迭代參數可以安全地為 1，這應該可以顯著改善手頭的問題，而且工作量很小。如果密鑰是具有至少 128 位熵的密碼（例如，從 64 個字元中隨機選擇的 22 個字元），這適用。
另一方面，如果密碼足夠簡單，可以記住，或者可以方便地鍵入，或者由沒有動機或沒有足夠判斷力的使用者選擇來使用一個好的密碼，那麼就需要某種密鑰拉伸，就像 PBKDF2 提供的那樣。然而 PBKDF2 是一種極差的鍵拉伸方法。10,000 次 PBKDF2 迭代對於使用 ASIC 的攻擊者來說幾乎是透明的，而對於使用 GPU 的攻擊者來說是可以克服的障礙。我建議盡快切換到更好的東西（涉及記憶體）：Argon2、scrypt，甚至是較小的 bcrypt，用於延長密碼的部分。即使你這樣做了，你也需要一個更好的選擇，而不是經常這樣做，以至於它成為一個瓶頸。
最通用的方法是記憶體。將密碼徹底熵拉伸一次到 128 位偽熵完全沒問題，將其寫入密碼（無論是在 RAM 中還是其他任何地方，只要訪問條件不比密碼本身寬鬆），然後使用它而不是密碼而不是進一步拉伸（只有派生，PBKDF2 可以做）。