使用 Fortuna PRNG 在计数器模式下使用 AES 进行随机访问加密：
我正在构建基于 AES 的文件加密，该加密必须能够在随机访问模式下工作（访问文件的任何部分）。例如，可以在 Counter 中使用 AES，但众所周知，我们需要一个不会使用两次的唯一序列。 在这种情况下，可以使用简化的 Fortuna PRNG（使用随机选择的特定于特定文件的唯一密钥来加密计数器）吗？这种方法有弱点吗？
因此，加密/解密可以如下所示：
在偏移处加密块：
rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)
在偏移处解密块：
rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq
一个观察。我自己想到了《福尔图娜》中使用的想法，后来肯定发现它已经被发明了。但正如我到处读到的那样，它的关键点是安全性，但还有另一个优点：可以说，它是一个很棒的随机访问伪随机数生成器（以简化形式）。因此，PRNG 不仅会产生非常好的序列（我用 Ent 和 Die Hard 对其进行了测试），而且如果您知道步骤号，还允许访问任何子序列。那么，在安全应用程序中使用 Fortuna 作为“随机访问”PRNG 通常可以吗？
编辑：
换句话说，我建议使用 Fortuna PRNG 作为调整，形成具有随机访问能力的可调整 AES 密码。我阅读了 Liskov、Rivest 和 Wagner 的著作，但无法理解操作模式下的密码和可调整密码之间的主要区别是什么。他们说，他们建议将这种方法从高层引入密码本身，但例如在我的例子中，通过调整对纯文本进行异或，这是否是一种调整？
I'm building file-encryption based on AES that have to be able to work in random-access mode (accesing any part of the file). AES in Counter for example can be used, but it is well known that we need an unique sequence never used twice.
Is it ok to use a simplified Fortuna PRNG in this case (encrypting a counter with a randomly chosen unique key specific to the particular file)? Are there weak points in this approach?
So encryption/decryption can look like this
Encryption of a block at Offset:
rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)
Decryption of a block at Offset:
rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq
One observation. I came to the idea used in Fortuna by myself and surely discovered later that it is already invented. But as I read everywhere the key point about it is security, but there's another good point: it is a great random-access pseudo random numbers generator so to speak (in simplified form). So the PRNG that not only produces very good sequence (I tested it with Ent and Die Hard) but also allow to access any sub-sequence if you know the step number. So is it generally ok to use Fortuna as a "Random-access" PRNG in security applications?
EDIT:
In other words, what I suggest is to use Fortuna PRNG as a tweak to form a tweakable AES Cipher with random-access ability. I read the work of Liskov, Rivest and Wagner, but could not understand what was the main difference between a cipher in a mode of operation and a tweakable cipher. They said they suggested to bring this approach from high level inside the cipher itself, but for example in my case xoring the plain text with the tweak, is this a tweak or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想您可能想了解一下“可调整的块密码”是如何工作的，并看看如何解决光盘加密的问题：磁盘加密理论。加密整个磁盘与您的问题类似：每个扇区的加密必须独立完成（您希望对不同偏移量的数据进行独立加密），但整个磁盘必须是安全的。这方面已经做了很多工作。维基百科似乎给出了很好的概述。
编辑添加：
重新编辑：是的，您正在尝试通过将调整与明文进行异或，用 AES 制作可调整的分组密码。更具体地说，您有 Enc(T,K,M) = AES (K, f(T) xor M)，其中 AES(K,...) 表示使用密钥 K 进行 AES 加密，f(T) 是以下函数调整（在你的情况下我猜是福尔图娜）。我简要浏览了您提到的论文，据我所知，有可能表明该方法不能产生安全的可调整分组密码。
这个想法（基于 Liskov、Rivest、Wagner 论文第 2 节的定义）如下。我们可以访问加密预言机或随机排列，并且我们想知道我们正在与哪一个进行交互。我们可以设置调整T和明文M，然后我们得到相应的密文，但我们不知道使用的密钥。以下是如何确定我们是否使用 AES(K, f(T) xor M) 结构。
选取任意两个不同的值 T、T'，计算 f(T)、f(T')。选择任意消息 M，然后将第二条消息计算为 M' = M xor f(T) xor f(T')。现在要求加密预言机使用调整 T 加密 M，并使用调整 T' 加密 M'。如果我们处理所考虑的构造，输出将是相同的。如果我们处理随机排列，输出几乎肯定会不同（概率为 1-2^-128）。这是因为 AES 加密的两个输入相同，因此密文也相同。当我们使用随机排列时，情况就不会如此，因为两个输出相同的概率是 2^-128。最重要的是，对输入进行异或调整可能不是一种安全的方法。
该论文给出了一些可以证明是安全结构的例子。最简单的似乎是 Enc(T,K,M) = AES(K, T xor AES(K, M))。每个块需要两次加密，但它们证明了这种结构的安全性。他们还提到了更快的变体，但它们需要额外的原语（几乎异或通用函数系列）。
I think you may want to look up how "tweakable block ciphers" work and have a look at how the problem of disc encryption is solved: Disk encryption theory. Encrypting the whole disk is similar to your problem: encryption of each sector must be done independently (you want independent encryption of data at different offsets) and yet the whole thing must be secure. There is a lot of work done on that. Wikipedia seems to give a good overview.
EDITED to add:
Re your edit: Yes, you are trying to make a tweakable block cipher out of AES by XORing the tweak with the plaintext. More concretely, you have Enc(T,K,M) = AES (K, f(T) xor M) where AES(K,...) means AES encryption with the key K and f(T) is some function of the tweak (in your case I guess it's Fortuna). I had a brief look at the paper you mentioned and as far as I can see it's possible to show that this method does not produce a secure tweakable block cipher.
The idea (based on definitions from section 2 of the Liskov, Rivest, Wagner paper) is as follows. We have access to either the encryption oracle or a random permutation and we want to tell which one we are interacting with. We can set the tweak T and the plaintext M and we get back the corresponding ciphertext but we don't know the key which is used. Here is how to figure out if we use the construction AES(K, f(T) xor M).
Pick any two different values T, T', compute f(T), f(T'). Pick any message M and then compute the second message as M' = M xor f(T) xor f(T'). Now ask the encrypting oracle to encrypt M using tweak T and M' using tweak T'. If we deal with the considered construction, the outputs will be identical. If we deal with random permutations, the outputs will be almost certainly (with probability 1-2^-128) different. That is because both inputs to the AES encryptions will be the same, so the ciphertexts will be also identical. This would not be the case when we use random permutations, because the probability that the two outputs are identical is 2^-128. The bottom line is that xoring tweak to the input is probably not a secure method.
The paper gives some examples of what they can prove to be a secure construction. The simplest one seems to be Enc(T,K,M) = AES(K, T xor AES(K, M)). You need two encryptions per block, but they prove the security of this construction. They also mention faster variants, but they require additional primitive (almost-xor-universal function families).
尽管我认为你的方法足够安全，但我没有看到比点击率有任何好处。您遇到了完全相同的问题，即您没有向密文注入真正的随机性。偏移量是已知的系统输入。尽管它是用密钥加密的，但它仍然不是随机的。
另一个问题是如何保证 FileUniqueKey 的安全？用密码加密？当您使用多个密钥时会引入一大堆问题。
计数器模式是加密随机访问文件的公认做法。尽管它有各种各样的漏洞，但都经过了充分研究，因此风险是可以衡量的。
Even though I think your approach is secure enough, I don't see any benefits over CTR. You have the exact same problem, which is you don't inject true randomness to the ciphertext. The offset is a known systematic input. Even though it's encrypted with a key, it's still not random.
Another issue is how do you keep the FileUniqueKey secure? Encrypted with password? A whole bunch issues are introduced when you use multiple keys.
Counter mode is accepted practice to encrypt random access files. Even though it has all kinds of vulnerabilities, it's all well studied so the risk is measurable.