AES加密多個文件
因此，如果我想使用 AES（相同密碼）加密文件夾中的所有文件，我會獲取每個文件並使用 PBKDF2 生成密鑰計劃。由於 PBKDF2 算法採用鹽，因此對於每個被加密的新文件，該鹽應該改變（以及密鑰調度）。現在，如果我想解密，那麼我載入明文鹽並為每個密文文件生成不同的密鑰調度。
它是否正確？如果是這樣，我看到的問題是建議的迭代次數以使加密更安全（例如 0.5 秒）將大大減慢加密過程，因為每個文件都需要一個冗長的密鑰派生過程。這只是安全加密過程的必要部分嗎？
謝謝！
您是正確的，對每個文件使用不同的鹽會減慢加密和解密速度，這與文件數量成正比。但這樣做沒有用。如果對手知道鹽對於使用相同密碼散列的多個文件是通用的（假設她可以從一個密文中以公平的機率辨識出正確的密碼，並且成本由PBKDF2主導），則對手將無濟於事。每個文件都有相同和不同的鹽，攻擊者的艱苦工作是找到密碼；當 salt 不同時，為其他文件重新計算 PBKDF2 的成本可以忽略不計。
因此，如果讓加密程序隨機生成每個文件共有的鹽，並為每個文件生成適當的 IV（例如 48 位文件號和 80 位零；這足以 $ 2^{48} $ 的文件 $ 2^{84} $ 每個字節，使用AES-CTR加密）；使用 PBKDF2 只計算一個密鑰；並將鹽和 IV 儲存為每個加密文件的標題。解密程序可以將密鑰記憶體在 RAM 中，以便在解密具有相同鹽的文件時重複使用（不應假設所有文件都具有相同的鹽，以防單獨加密的文件合併到同一目錄中）。
當使用其他分組密碼操作模式（例如 CBC、CFB 或 OFB）對多個大文件進行加密時，您可能會接近一個密鑰的合理使用限制。出於這個原因，或者只是為了讓您安心，您可能希望每個文件有一個密鑰。這可以通過為每個加密會話從密碼和主鹽（例如隨機）生成一個公共的“慢速”主密鑰以及從主密鑰生成一個“快速”派生密鑰，在多個文件上攤銷從密碼派生的密鑰的同時完成每個文件的二級鹽（例如文件索引），兩個鹽都在加密文件的標題中。“快速”推導可以使用 PBKDF2 和最小迭代計數c =1，或者只有一個HMAC。
另外：您可能需要考慮scrypt而不是 PBKDF2（至少對於主密鑰），因為它為給定的時間成本提供了更好的安全性，如 scrypt 論文（2009）的下表中所總結的那樣：
更新（2020 年）：最先進的技術已經發展。比特幣挖礦表明，以高速率 (220 TH/s) 和效率 (15 pJ/H) 執行 SHA-256 的專用 ASIC 可以以幾千美元的價格上市。這使得依靠在標準硬體上執行的 PBKDF2-HMAC 在高安全性應用程序中擴展使用者選擇的密碼變得站不住腳。Scrypt 仍然很強大，但是密碼雜湊的新最佳實踐是密碼雜湊競賽Argon2的獲勝者。
確實沒有任何可衡量的安全性。也是不一致的。如果您有 30 個 1KB 的文本文件，您將生成 30 個新的時間表，但如果它是一個 20MB 的影片，您將對所有數據使用一個時間表。
實際上，這取決於您的加密模式。例如，如果您使用 CFB，則 iv 無論如何都會根據前一個塊而改變，因此沒有理由繼續切換時間表。