加密方案建議
我正在編寫一個小程序來加密和解密文件。我在 CTR 模式下使用 AES 加密，它採用由 KDF（腳本）生成的密鑰。我讀過一些關於密碼學的文章，但我有一些疑問。為了加密文件，我將它分成塊，然後用 AES 加密它們，為每個塊生成一個隨機數。對於密鑰派生，我為每個文件生成一個隨機鹽。我是否需要為每個塊或每個文件使用不同的鹽就足夠了？我需要使用 CTR 模式進行填充嗎？我應該遵循其他指導方針來正確加密嗎？謝謝！！
我在 CTR 模式下使用 AES 加密，它採用由 KDF（腳本）生成的密鑰。
除非您有充分的理由不這樣做，否則您應該使用經過身份驗證的加密。 例如，AES-GCM 或帶有 HMAC-SHA256 的 AES-CTR 在 encrypt-then-MAC 組合中，如scrypt(1) 實用程序使用。如果您不確定，請使用經過身份驗證的加密。
- 如果你確定你有充分的理由不使用經過身份驗證的加密，你應該有一個設計文件闡明（a）你試圖用什麼資源完成什麼，（b）對手有什麼權力破壞這些資源，以及(c) 儘管如此，您仍想向合法使用者提供哪些安全屬性——以及 (b) 中列舉的對手的權力排除修改密文的能力的明確理由。
實際上，無論如何您都應該編寫該設計文件！但是，如果您沒有明確的理由，使用未經身份驗證的加密肯定會引起很多人的注意。
對於密鑰派生，我為每個文件生成一個隨機鹽。我是否需要為每個塊或每個文件使用不同的鹽就足夠了？
只要您為每個文件獨立生成每個密鑰（您已經這樣做了，如果您使用為每個文件獨立生成的隨機鹽從密碼中派生它）並且從不在文件之外重用它，您就可以安全地重用所有密鑰只要您為每個塊使用不同的隨機數，文件中的塊。
為了加密文件，我將它分成塊，然後用 AES 加密它們，為每個塊生成一個隨機數。
使用 AES-CTR（或 AES-GCM）的隨機 nonce通常是不安全的，因為對於看似大量的數據，衝突機率非常高，並且 nonce 重用是災難性的。
在這種情況下，您可能永遠不會擁有超過幾百萬塊的文件，這對於 64 位隨機數是安全的，但我不知道，我不會依賴它。即使您選擇 96 位隨機數（如果您的數據塊不超過 1 GB，您可以安全地使用它），幾十億的數據塊也可能是相當大的數據量。
- 如果您使用 NaCl crypto_secretbox_xsalsa20poly1305，隨機 nonce 的衝突機率可以忽略不計，因為它們的長度為 192 位，比 AES 直接或有效支持的長度要長。
即使使用經過身份驗證的加密，攻擊者也可能能夠剪切和粘貼塊以將它們打亂或刪除或複制它們。
- 您可以通過使用順序隨機數來用一塊石頭殺死兩隻鳥：使用文件中塊的序列號作為隨機數。 即使使用 64 位隨機數，您也永遠不會順序發生衝突（您將首先達到 128 位分組密碼的生日界限，除非您並行計算，否則這將需要幾個世紀），並且如果您*要求nonce 匹配文件中塊的序列號，*那麼即使是可以修改文件的對手也無法將塊打亂。
我需要使用 CTR 模式進行填充嗎？
CTR 模式不需要填充。CTR 模式只是一種使用帶有密鑰和每個消息隨機數的分組密碼來生成您想要的任何位長度的一次性填充的方法。
說了這麼多：考慮對多塊文件使用現有結構嗎？