在資源受限的移動設備中加密文件

Question

所以基本問題是在資源受限設備中加密文件。 我已經使用相當危險的方法使用兩個文件流，其中

1. 的FileStream 1被從文件中讀取並將其複製到一個字節數組
2. 字節數組的內容被加密。
3. FileStream 2，將字節寫回相同的文件。

這工作得很好，但有搞亂了文件的一個很好的機會，如果加密中途停止等

所以正常的方法是編寫到一個臨時文件，然後將其移動到原來的位置並替換原始文件。

但是，問題出在資源（特別是存儲）非常有限的手機上，創建可以說另一個200MB或300MB的文件可能是不可能的。

那麼在Mobile Devies中有什麼方法可以解決這個問題呢？我是否必須在空間之間進行賭博並搞亂文件？

Answer 1

的一種方式，可能是：

1. 的FileStream 1從文件中讀取並將其複製到一個字節數組
2. 你讀的字節數，被寫入與您的緩衝區大小相同的小型「scratch」文件，以及最後一個塊的位置成功讀取。
3. 字節數組的內容被加密。
4. FileStream 2，將字節寫回相同的文件。

如果過程中斷，請檢查臨時文件以查看上次位置的位置。然後你可以從那裏重新啓動進程，並且仍然可以加密整個文件。 （如果你想恢復原始文件，你需要加密剩餘的塊，然後解密它）。

當然，只有在使用加密算法時，此過程纔有效，該算法在加密當前塊時依賴於前面塊的結果。根據您選擇的算法，您可能需要存儲更多一點。

Answer 2

首先，您可以隨時檢查是否有足夠的空間將您的陣列寫入tmp文件。

接下來，你問的問題不是一個真正的問題，因爲如果你正在加密，你已經讀完整的文件到數組。加密完成後，您可以確定字節數組已加密。如果情況並非如此，該函數將拋出異常。因此，在步驟3中，當您寫入文件時，可以覆蓋它。

編輯 我現在認識到，你部分加密和寫入文件，否則它不適合內存。那是對的嗎？使這一過程更加安全一點

Answer 3

我是否必須在空間和賭場之間進行賭博？

基本上，是的。
如果空間限制迫使您就地轉換（加密），則不存在回滾選項。

接下來的問題是大小。如果您的轉換（可以）增加數據的大小，則您的操作空間非常有限。如果ResultSize>（InputSize + Buffer）那麼你不會成功。

在加密的情況下，您可以在CryptoStream前面使用CompressStream，但是您將無法預測它是否會起作用。

總之，在移動設備上，您已達到極限。您將不得不強制使用額外的內存設備。