AES-XTS 是否被認為可以安全地使用相同的密鑰加密多個文件？
我想知道在EncFS中將密碼模式更改為 AES-XTS是否是個好主意。EncFS 在 CBC 模式下使用 AES 直到最後一個 1KB 塊，如果
len(block) < 1KB. 這確保了len(plaintext) == len(ciphertext).該設計似乎有些複雜，但考慮到這些決定（可能？）是在任何相關標準發布之前做出的，這是可以理解的。
我主要擔心的是 AES-XTS 似乎是為儲存在塊設備中的數據而設計的，而不是為“使用者空間加密文件系統”而設計的。在加密的使用者空間文件系統中，每個文件都是一個“塊設備”，每個“塊設備”都使用相同的密鑰。
除了加密同一個文件兩次會產生相同的密文（如果不使用每個文件的密鑰）的明顯問題之外，我們如何攻擊這種設計？:)
謝謝你。
額外的說明/動機
EncFS 的預設選項
EncFS在創建卷時有幾個選項。預設情況下，文件使用唯一的、不可預測的 ivs 加密；塊未經過身份驗證（存在每塊 MAC 選項，但出於效率考慮已禁用）；EncFS 中的“塊”預設為 1024 字節。
為什麼有人要禁用每個文件的 ivs？
在 EncFS 中禁用每個文件的 ivs 會引發幾個潛在問題：
- 水印攻擊
- 使用來自不同文件的塊進行複制粘貼攻擊
- 由於可以使用流密碼對最後一個塊進行加密，因此可以重用密鑰流。或者不是，因為使用了一些魔法洗牌操作。
- 額外資訊洩露
但是，許多人將 EncFS 與基於雲的儲存解決方案一起使用，例如 Dropbox 和 Google Drive。一些商業服務存在/基於 EncFS，甚至禁用 per-file IVs。我與此類公司沒有任何關聯。
禁用 per-file ivs 後，特定卷內的重複數據刪除將非常有效。相同塊偏移量上的相同明文將具有相同的密文。從頻寬/空間效率的角度來看，這是一個非常理想的特性。從安全的角度來看，它不是。
所以這個問題可以改寫為：使用 AES-XTS（它比 AES-CBC 延展性更差，更容易並行化，但它可以洩漏更多資訊，因為它不連結）沒有每個文件的密鑰是可接受的安全折衷，如果試圖優化雲儲存服務的捲？啟用這樣的設計是否可以接受？
“一個 XTS-AES 密鑰不應與多個密鑰範圍相關聯。原因是使用相同密鑰和相同索引加密多個塊會引入可能用於系統攻擊的安全漏洞。在特別是，密鑰重用可以實現簡單的剪切和粘貼攻擊。”
你在這裡嚴重違反了保修。我想你知道這…
“來自Rogaway的證明只要不使用相同的密鑰來加密超過 1 TB 的數據（即 q=236 塊），就會產生強大的安全保證。在這種情況下，任何攻擊的成功機率都不會超過 2^53（即大約八萬億分之一）。隨著更多數據在同一密鑰下加密，這種安全保證會惡化。例如，當對 PB 的數據使用相同的密鑰時，諸如 D.4.2 中的攻擊的成功機率最多約為 2^37（即大約萬億分之一），而對於 EB 的數據，成功機率最高最多約為 2^17（即，大約百萬分之八）。
所以我猜在權衡完全被打破之前你可能有一些空間。
此外，如果雲儲存系統可以防止任何內容在不首先加密的情況下被寫入使用者空間，（或防止任何自己沒有加密的內容被解密），那麼它可能能夠防止一些複製/粘貼攻擊（來自使用者）。由於所有加密/解密/寫入都是從攻擊使用者遠端完成的，因此消除了 IEEE 對某些類型的被動攻擊和隨機數據攻擊的一些擔憂。
好的，這是我最慷慨的回答。你問的是一個形式的問題，“有這個安全標準。我可以扔掉它的主要部分，讓它對其他東西有用嗎？”
雖然通過您的修改開始對 AES-CBC 和 AES-XTS 進行比較密碼分析是非常誘人的，但對所有此類問題的唯一負責任的答案必須是，“不，這會給你一些被破壞和未經驗證的東西，相當於只是從頭開始編造一些東西。你不應該這樣。加密的第一條規則是不要建立自己的加密。 “
我強烈建議從頭開始解決這個問題，“我想要一個完成 X、Y 和 Z 的模式或協議，但我不關心攻擊 A、B 或 C。有沒有這樣的模式？如果沒有，那是什麼？離得最近嗎？” 也許沒有，您必鬚麵對重複數據刪除或安全性的艱難選擇。但是，誰知道呢，你可能會發現有一些你甚至沒有考慮過的東西可以滿足你的設計目標。
祝你好運！