Encryption 在内存和存储受限的系统上加密和/或解密大型文件（AES），使用；灾难恢复“；

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

所以，让我们假设一个1GB的文件，需要在给定的系统上进行加密和解密

问题是，该系统的可用内存不足512 mb，存储空间约为1.5 GB（给定或获取），因此，对于“板载”文件，我们有约500 mb的“硬盘刮擦空间”和不足512 mb的RAM可供“播放”

在加密或解密过程中，系统不太可能在任何时刻经历“计划外断电”，并且需要能够在再次通电后成功恢复加密/解密过程（这似乎是一个额外的棘手问题）

问题是:

1） 这完全可行吗

2） 最好的策略是什么

a） 加密/解密时只需很少的临时空间（在解密/加密时不能将整个文件放在周围，需要以某种方式“动态”截断它…）

及

b） 实施能够在如此受限的环境中工作的灾难恢复

附言： 使用的密码必须是AES

我专门研究了AES-CTR，但对于灾难恢复shenanigan来说，这似乎不是一个好兆头，因为在这样的环境中，您无法将整个解密文件保存到最后

[经编辑添加]

---

我想我终究还是会用iSeries的方式来做。

你必须将大文件分块处理。断开一段文件，对其进行加密，并将其保存到磁盘；保存后，丢弃未加密的片段。重复一遍。要解密，抓取一个加密的块，解密它，存储未加密的块。丢弃加密的片段。重复一遍。解密完这些片段后，将它们连接起来。

这肯定是可行的

---

“最大的”（但不是很大）问题是，当加密128 Mb的原始数据时，需要将其从源文件中删除。为此，您需要将文件的其余部分复制到开头，然后截断文件。这需要时间。在此步骤中，可以关闭电源，但您不太关心——您知道已加密数据的大小（如果您使用大小为16字节的块加密数据，则加密数据的大小将等于已解密文件中已删除或必须删除的大小）。不幸的是，发明这个方案似乎比解释它更容易：），但我真的认为除了额外的复制操作之外没有什么问题，这会减慢进程。不，没有通用的方法可以从文件的开头剥离数据，而不将剩余部分复制到文件的开头

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

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

读取一个加密/解密数据块（比如10兆字节）

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

记录划痕已完成的事实

在同一位置对原始文件进行写刮

记录已成功复制划痕的事实

转到1

如果在第1阶段后出现硬崩溃，而第1阶段和第2阶段不一致，则只需重新启动并假设具有最早p的阶段是好的。 如果在第2阶段期间或之后发生硬崩溃，您将损失10兆字节的工作：但是AES和P是好的，所以您只需重复第2阶段。 如果您在第3阶段崩溃，那么在恢复时您将找不到第4阶段的标记，因此您将知道划痕是不可靠的，必须重新生成。有了STAGE1/STAGE2，您就可以这样做了。 如果你在第四阶段崩溃，你会相信划痕必须再生，即使你可以避免——但在再生过程中除了一点时间之外，你什么都没有损失。 同样，如果您在第5阶段崩溃，或者在第6阶段提交到磁盘之前崩溃，您只需重复第5和第6阶段。您知道您不必重新生成SCRATCH，因为第4阶段已提交到磁盘。如果你在第1阶段后崩溃，你仍然有一个好的草稿可以复制

所有这些都假设10 MB的数据量超过缓存（如果写回，则为操作系统+硬盘）的数据量。如果不是，则提升到32或64 MB。复苏速度将相应放缓

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

---

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

Hmmmm。。。好的，是的，AES-CBC似乎是可行的，因为每个下一个数据块基本上都是用前一个数据块的最后16个字节加密的，所以只要知道“最后一个好的加密数据块”或者，在加密的情况下，“最后一个好的明文数据块”（通过某种日志技巧，比如有一个额外的文件存储最近10次操作的数据）amrite，应该有一个直接的“灾难恢复”路径？啊，是的，的确，截断只适用于文件末尾。但我明白你的意思了，我想：）谢谢，我会尝试这样做（并使用所有复制到badger的糟糕性能，在这个…东西上复制一个更大的硬盘。）为什么你不能在普通数据上复制加密数据？您可以保存状态，不是吗？@owlstead如果发生电源故障，很有可能会发生损坏或数据丢失。仅保存状态、映射文件、写入草稿行、保存状态、加密到原始状态并再次保存状态是行不通的？当然，您需要一个草稿行和状态，但是每次移动大部分文件似乎有点浪费（或者实际上是大量浪费）。@owlstead是的，这就是日志文件系统的工作方式（包括我们的solf）。我不认为复制文件的其余部分会像在原地写入加密数据一样损坏原始文件。太可怕了