4

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

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

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

系统在加密或解密期间的任何时候都不太可能遇到“计划外断电”，并且需要在再次通电后能够成功恢复加密/解密过程（这似乎是一个额外令人不快的坚果处理）。

问题是：

1）它是否可行:)？

2）什么是最好的策略

a) 使用如此小的暂存空间进行加密/解密（在解密/加密时不能将整个文件放在周围，需要以某种方式“即时”截断它......）

和

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

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

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

[编辑添加]我想我会按照 Iserni 的方式来做。

4

3 回答 3

5

这是可行的，只要您有办法将 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 阶段已提交到磁盘。

所有这一切都假设 10 MB 大于缓存（如果写回，则为操作系统 + 硬盘）的数据价值。如果不是，请提高到 32 或 64 MB。恢复将成比例地变慢。

如果这些功能可用，则在每个写入阶段完成后刷新（）和同步（）可能会有所帮助。

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

于 2012-07-02T20:27:45.420 回答
1

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

于 2012-07-02T19:51:32.533 回答
0

这当然是可行的。

“最大”（但一点也不大）的问题是，当您加密 128 Mb 的原始数据时，您需要将它们从源文件中删除。为此，您需要将文件的其余部分复制到开头，然后截断文件。这需要时间。在这一步可以关闭电源，但你并不在意——你知道你加密的数据的大小（如果你通过大小多到 16 字节的块来加密数据，加密数据的大小将是等于已经或必须从解密文件中删除的大小）。不幸的是，发明这个方案似乎比解释它更容易:)，但除了额外的复制操作会减慢这个过程之外，我真的没有看到任何问题。不，有'

于 2012-07-02T20:22:48.327 回答