加密资源受限的移动设备中的文件

Question

所以基本问题是加密资源受限设备中的文件。 我使用了一种相当危险的方法来使用两个FileStream，其中

1. FileStream 1正在从文件读取并将其复制到字节数组
2. 字节数组的内容已加密。
3. FileStream 2，将字节写回同一文件。

这样可以正常工作，但如果加密中途停止等，则很有可能弄乱文件。

因此，通常的方法是写入临时文件，然后将其移动到原始位置并替换原始文件。

然而问题是在资源（特别是存储）非常有限的移动电话中，创建可以说另外200MB或300MB的文件可能是不可能的。

那么在Mobile Devies中有哪些方法可以解决这个问题？我是否必须在空间之间进行赌博并弄乱文件？

Answer 1

使这个过程更安全的一种方法可能是：

1. FileStream 1正在从文件读取并将其复制到字节数组
2. 您读取的字节将写入与缓冲区大小相同的小“临时”文件，以及成功读取的最后一个块的位置。
3. 字节数组的内容已加密。
4. FileStream 2，将字节写回同一文件。

如果进程中断，请检查暂存文件以查看上次位置的位置。然后，您可以从那里重新启动该过程，并仍然可以加密整个文件。 （如果你想恢复原始文件，你会加密剩余的块，然后解密它。）

当然，此过程仅在您使用加密算法时才有效，该加密算法在加密当前块时依赖于前面块的结果。根据您选择的算法，您可能需要再存储一些。

Answer 2

首先，您始终可以检查是否有足够的空间将数组写入tmp文件。

接下来，您提出的问题并不是一个真正的问题，因为如果您正在加密，那么您已经将完整的文件读取到了数组。加密完成后，您可以确保字节数组已加密。如果不是这种情况，该函数将抛出异常。因此，在步骤3中，当您写入文件时，您可以覆盖它。

修改 我现在意识到你加密并写入部分文件，否则它不适合ram。这是对的吗？

Answer 3

  

我是否必须在空间之间进行赌博并弄乱文件？

基本上，是的。
如果空间限制迫使您就地转换（加密），则没有回滚选项。

下一个问题是尺寸。如果您的转换（可以）增加数据的大小，则您的操作空间非常有限。如果ResultSize＆gt; （InputSize + Buffer）然后你就不会成功。

在加密的情况下，您可以在CryptoStream前使用CompressStream，但是您无法预测它是否会起作用。

简而言之，在移动设备上，您已达到限制。您必须要求额外的内存设备。