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 回答