逐塊加密單個文件，每個塊使用不同的密鑰 (AES)
逐塊加密單個文件，每個塊使用不同的密鑰。
我是一個安全新手（之前只上過 2 門安全課程）
但目前我正在為我的 Android 應用程序使用這種加密方法，它執行客戶端加密並將每個加密塊上傳到不同的雲儲存（Dropbox、Box、Google Drive、SkyDrive ) {該應用程序尚未在Google市場上發布，併計劃在穩定後發布}
但不知何故，我認為它似乎在做額外的工作而沒有增加額外的安全級別。
步驟如下：
- 使用 PBKDF2，我從使用者提供的兩個密碼中派生出 1 個主密鑰 (Km) 和 1 個數據庫密鑰 (Kd)
- 然後，我使用帶有隨機鹽的 PBKDF2 從 (Km) 進一步派生多個部分密鑰 (Ki…Kn)。鹽 (Si…Sn) 儲存在使用 (Kd) 加密的數據庫中
- 然後我將一個文件分成多個塊（4MB），並用不同的部分密鑰（Ki…Kn）加密每個塊
- 哪個鹽與哪個塊相關聯的資訊作為文件元數據儲存在數據庫中。（數據庫也儲存在雲儲存中）
- 相同的步驟用於解密，以相反的方式（從使用者那裡獲取 2 個密碼，導出 Km 和 Kd，解密數據庫，從數據庫中檢索鹽，從 Km + salts 導出 Ki…Kn，解密每個文件塊，將每個塊合併回來到原始文件。
初始化密碼時也使用初始化向量（iv），但我不會弄亂它。我遵循原始方法，只是將它作為純文字附加到我的文件塊前面。
據我了解 Salt 的用法是我們不需要保密。因為它只會使蠻力攻擊變慢。
但就我而言，我對鹽保密（有些人稱之為胡椒，或共享秘密）
我的主要問題是：
1）我的設計有缺陷嗎？
2）如果它沒有缺陷，它是否提供額外的安全性？而不是僅僅減慢蠻力。還是我的設計完全沒有意義和多餘？
- 歡迎任何其他意見。
第1步：幹得好，這是正確的方法。您還可以使用 bcrypt 或 scrypt 來獲得額外的阻力。確保您選擇了足夠強的參數，即 64 位 salt 和 10000 rounds absolute minimum。
第2步：不！一旦你有一個強大的派生主密鑰，你就不需要對從這個主密鑰派生的任何密鑰應用 PBKDF2。您只是在浪費時間和精力，而且根本無法擴展。將 HMAC 與隨機 nonce 一起使用，並使用主密鑰作為密鑰。
第 3 步：為什麼不使用單個（派生的）密鑰加密整個文件？為什麼要將文件拆分成塊？如果您確實有充分的理由，請忽略這一點。
第4步：我..假設。
第5步：是的。
我的設計有缺陷嗎？好吧，我不會騙你，這有點奇怪。如果您只想加密文件，則無需將文件拆分為塊。你讓它變得不必要的複雜。除非你有充分的理由。現在真正的問題是您沒有適當的完整性檢查和身份驗證機制。那很不好。
**還是我的設計完全沒有意義和多餘？**坦率地說，是的，是的。
歡迎任何其他意見。 不要設計自己的真實世界密碼系統。要麼你用簡單的方法做，讓有能力的人（或者更好的是，多個）在部署它之前檢查它，或者根本不做。盲目地將密碼學扔到一個問題上不是正確的方法。
我對這個問題的問題是你沒有明確的目標。你在保護什麼？你的威脅模型是什麼？數據庫儲存在哪裡？誰或什麼將訪問它？ETC..
如果不知道這一點，“額外的安全性”就沒有任何意義。比什麼更安全，反對什麼？
TL;DR：設計存在缺陷且過度設計，設計師不應該設計用於現實世界的密碼系統（當然可以進行實驗）。最好使用現有的文件加密方案（Android 應該有數百萬，但 OpenSSL 會很好）並將元數據儲存在安全數據庫中。