5

我正在构建基于 AES 的文件加密，它必须能够在随机访问模式下工作（访问文件的任何部分）。例如，可以在 Counter 中使用 AES，但众所周知，我们需要一个从未使用过两次的唯一序列。在这种情况下是否可以使用简化的 Fortuna PRNG（使用特定于特定文件的随机选择的唯一密钥加密计数器）？这种方法有弱点吗？

所以加密/解密看起来像这样

在偏移量处加密块：

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)

在 Offset 处解密块：

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq

一项观察。我自己想到了 Fortuna 中使用的想法，后来肯定发现它已经被发明了。但正如我所读到的，关于它的关键点是安全性，但还有另一个好处：可以说它是一个很棒的随机访问伪随机数生成器（以简化形式）。因此，PRNG 不仅可以产生非常好的序列（我用 Ent 和 Die Hard 对其进行了测试），而且如果您知道步骤编号，还允许访问任何子序列。那么在安全应用程序中使用 Fortuna 作为“随机访问”PRNG 通常可以吗？

编辑：

换句话说，我建议使用 Fortuna PRNG 作为调整，以形成具有随机访问能力的可调整 AES 密码。我阅读了 Liskov、Rivest 和 Wagner 的作品，但无法理解操作模式中的密码和可调整密码之间的主要区别是什么。他们说他们建议将这种方法从密码本身的高层引入，但例如在我的情况下，通过调整对纯文本进行异或，这是否是调整？

4

2 回答 2

5

我想你可能想看看“可调整分组密码”是如何工作的，看看磁盘加密问题是如何解决的：磁盘加密理论。加密整个磁盘与您的问题类似：每个扇区的加密必须独立完成（您希望对不同偏移量的数据进行独立加密），但整个事情必须是安全的。在这方面做了很多工作。维基百科似乎给出了一个很好的概述。

编辑添加：重新编辑：是的，您正试图通过对明文进行异或调整来从 AES 中制作可调整的分组密码。更具体地说，您有 Enc(T,K,M) = AES (K, f(T) xor M) 其中 AES(K,...) 表示使用密钥 K 进行 AES 加密，而 f(T) 是调整（在你的情况下，我猜是财神）。我简要查看了您提到的论文，据我所知，可以证明这种方法不产生一个安全的可调整分组密码。这个想法（基于 Liskov、Rivest、Wagner 论文第 2 节的定义）如下。我们可以访问加密预言机或随机排列，我们想知道我们正在与哪一个进行交互。我们可以设置 Tweak T 和明文 M，然后我们得到相应的密文，但我们不知道使用的密钥。下面是如何确定我们是否使用构造 AES(K, f(T) xor M)。选择任意两个不同的值 T、T'，计算 f(T)、f(T')。选择任何消息 M，然后将第二条消息计算为 M' = M xor f(T) xor f(T')。现在要求加密预言机使用tweak T 加密M，并使用tweak T' 加密M'。如果我们处理考虑的结构，输出将是相同的。如果我们处理随机排列，输出几乎肯定会（概率为 1-2^-128）不同。这是因为 AES 加密的两个输入是相同的，所以密文也是相同的。当我们使用随机排列时，情况并非如此，因为两个输出相同的概率是 2^-128。底线是对输入进行异或调整可能不是一种安全的方法。

该论文给出了一些可以证明是安全结构的示例。最简单的似乎是 Enc(T,K,M) = AES(K, T xor AES(K, M))。每个块需要两次加密，但它们证明了这种结构的安全性。他们还提到了更快的变体，但它们需要额外的原语（几乎异或通用函数系列）。

于 2009-09-23T11:23:27.213 回答
1

尽管我认为您的方法足够安全，但我认为 CTR 没有任何好处。您有完全相同的问题，即您没有向密文注入真正的随机性。偏移量是已知的系统输入。即使它是用密钥加密的，它仍然不是随机的。

另一个问题是如何保证 FileUniqueKey 的安全？用密码加密？当您使用多个键时，会引入一大堆问题。

计数器模式是加密随机访问文件的公认做法。尽管它有各种各样的漏洞，但都经过充分研究，因此风险是可以衡量的。

于 2009-09-22T21:51:28.317 回答