我有一个相当笼统的问题，所以如果有点模糊，请原谅。
因此，我们假设有一个 1GB 的文件，需要在给定系统上加密并随后解密。
问题是系统的可用内存少于 512 MB，存储空间大约为 1.5 GB（给定或需要），因此，对于“板载”文件，我们有大约 500 MB 的“硬盘暂存空间”，并且少于 512 MB mb RAM 来“玩”。
系统在加密或解密过程中的任何时刻都不太可能经历“计划外断电”，并且需要能够在再次通电后成功恢复加密/解密过程（这似乎是一个额外令人不快的坚果）处理）。
问题是：
1）这是否可行：） ?
2）最好的策略是什么
a）用如此小的暂存空间进行加密/解密（在解密/加密时不能让整个文件散落在各处，需要以某种方式“即时”截断它......）
and
b) 实施可在如此受限的环境中发挥作用的灾难恢复？
附：
使用的密码必须是 AES。
我专门研究了 AES-CTR，但在无法将整个解密文件保存到最后的环境中，它似乎对于灾难恢复恶作剧来说并不是一个好兆头......
[编辑添加]
我想我最终会按照伊塞尔尼的方式去做。
如果您有办法将 AES 状态向量与文件位置一起保存，这是可行的。
- 将 AES 状态和文件位置 P 保存到文件 STAGE1 和 STAGE2
- 读取一大块（例如 10 MB）加密/解密数据
- 将解密/加密的块写入外部暂存区 SCRATCH
- 记录 SCRATCH 已完成的事实
- 在原始文件的相同位置写入 SCRATCH
- 记录 SCRATCH 已成功复制的事实
- Goto 1
如果您在第 1 阶段后发生严重崩溃，并且 STAGE1 和 STAGE2 不一致，您只需重新启动并假设最早 P 的阶段是好的。
如果您在第 2 阶段期间或之后发生严重崩溃，您将损失 10 MB 的工作量：但 AES 和 P 都很好，因此您只需重复第 2 阶段即可。
如果你在第 3 阶段崩溃，那么在恢复时你将找不到第 4 阶段的标记，因此会知道 SCRATCH 不可靠，必须重新生成。有了STAGE1/STAGE2，你就能做到这一点。
如果你在第 4 阶段崩溃，你会相信 SCRATCH 必须重新生成，即使你可以避免这种情况 - 但除了一点时间之外，你在再生中不会损失任何东西。
同样，如果在第 5 阶段或第 6 阶段提交到磁盘之前崩溃，您只需重复阶段 5 和 6。您知道不必重新生成 SCRATCH，因为阶段 4 已提交到磁盘。如果你在第 1 阶段之后崩溃，你仍然有一个很好的 SCRATCH 可以复制。
所有这些都假设 10 MB 超过了缓存（操作系统 + 硬盘，如果回写）的数据价值。如果不是，请增加到 32 或 64 MB。恢复速度会相应变慢。
如果这些函数可用，在每个写入阶段完成后，刷新（）和同步（）可能会有所帮助。
总写入时间比正常情况的两倍多一点，因为需要“写入两次”才能确定。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
