通过"灾难恢复"在内存和存储受限系统上加密和/或解密大文件(AES)

Question

我有一个相当普遍的问题,所以请原谅,如果它有点模糊.

所以,让我们假设一个1GB的文件,需要加密,然后在给定的系统上解密.

问题是系统的可用内存少于512 MB,存储空间约为1.5 GB(赠送或取出),因此,对于"板载"文件,我们有大约500 MB的"硬盘空间"且小于512 mb RAM"玩".

系统在加密或解密期间的任何时刻都不会遇到"计划外断电",并且需要能够在再次通电后成功恢复加密/解密过程(这似乎是一个非常令人不愉快的事情.解决).

问题是:

1)它是否可行:)？

2)什么是最好的策略

a)使用如此少的临时空间加密/解密(在解密/加密时不能将整个文件放在周围,需要在某种程度上"在运行中"截断它...)

和

b)实施能够在这样一个受限制的环境中工作的灾难恢复？

PS:使用的密码必须是AES.

我专门研究了AES-CTR,但它似乎并没有为灾难恢复shenanigan带来好处,在这种环境中你无法将整个解密文件保留到最后......

[编辑添加]我想我毕竟会以Iserni的方式做到这一点.

Answer 1

只要您有将AES状态向量与文件位置一起保存的方法,这是可行的.

1. 将AES状态和文件位置P保存到文件STAGE1和STAGE2
2. 读取一个块(例如,10兆字节)的加密/解密数据
3. 将解密/加密的块写入外部临时SCRATCH
4. 记录SCRATCH完成的事实
5. 将SCRATCH写在原始文件的相同位置
6. 记录SCRATCH已成功复制的事实
7. 转到1

如果你在第1阶段之后遇到硬碰撞,并且STAGE1和STAGE2不同意,你只需重新启动并假设最早的P为好的阶段.如果你在第2阶段或之后遇到硬碰撞,你将失去10兆字节的工作:但AES和P都很好,所以你只需重复第2阶段.如果你在第3阶段崩溃,那么在恢复时你将找不到第4阶段的标记,因此将知道SCRATCH不可靠并且必须重新生成.拥有STAGE1/STAGE2,你就可以这样做.如果你在第4阶段崩溃,你会相信必须重新生成SCRATCH,即使你可以避免这种情况 - 但除了一点时间你再也没有失去任何东西.出于同样的原因,如果您在5中崩溃,或者在6之前将其提交到磁盘,您只需重复第5和第6阶段.您知道您不必重新生成SCRATCH,因为第4阶段已提交到磁盘.如果你在第1阶段后崩溃,你仍然会有一个好的SCRATCH来复制.

所有这些都假定10 MB不仅仅是缓存(OS +硬盘,如果回写)的数据.如果不是,则提高到32或64 MB.恢复速度将相应较慢.

如果这些函数可用,则在每个写阶段完成后,flush()和sync()可能会有所帮助.

总写入时间是正常的两倍多,因为需要"写两次"才能确定.