encryption - 在内存和存储受限的系统上加密和/或解密大文件 (AES)，使用 "catastrophe recovery"

Question

我有一个相当笼统的问题，所以如果它有点含糊，请原谅。

因此，让我们假设一个 1GB 的文件需要在给定的系统上加密然后解密。

问题是系统的可用内存少于 512 mb 和大约 1.5 GB 的存储空间(给予或接受)，因此，使用“板载”文件，我们有大约 500 MB 的“硬盘暂存空间”和少于 512 mb RAM“玩”。

系统在加密或解密过程中的任何时刻都不太可能遇到“计划外断电”，并且需要在再次上电后能够成功恢复加密/解密过程(这似乎是一个非常令人不快的坚果处理)。

问题是:

1) 它完全可行 :) 吗？

2)什么是最好的策略

a) 用这么小的暂存空间加密/解密(在解密/加密时不能让整个文件到处都是，需要以某种方式“即时”截断它......)

和

b) 实现可在这种受限环境中工作的灾难恢复？

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

我专门研究了 AES-CTR，但在无法将整个解密文件保留到最后的环境中，它似乎并不是灾难恢复恶作剧的好兆头……

[编辑添加]
我想我终究会以伊塞尔尼的方式来做这件事。

Answer 1

这是可行的，前提是您有办法将 AES 状态向量与文件位置一起保存。

将 AES 状态和文件位置 P 保存到文件 STAGE1 和 STAGE2

读取一大块(比如 10 兆字节)的加密/解密数据

将解密/加密的块写入外部暂存 SCRATCH

记录 SCRATCH 完成的事实

将 SCRATCH 写在原始文件的同一位置

记录 SCRATCH 复制成功

转到 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 超过缓存(操作系统 + 硬盘，如果写回)的数据值(value)。如果不是，请提高到 32 或 64 MB。恢复会相应地变慢。

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

总写入时间比正常情况下两倍多一点，因为需要“写入两次”才能确定。