Arbitrary encryption using AES In counter mode using Fortuna PRNG:

Question

I am building file encryption based on AES, which should be able to work in random access mode (access to any part of the file). For example, you can use AES in Counter, but it is well known that we need a unique sequence that has never been used twice. Is it possible to use the simplified Fortuna PRNG in this case (encryption of the counter with a randomly selected unique key specific to a specific file)? Are there any flaws in this approach?

Thus, encryption / decryption may look like this:

Block encryption at offset:

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

Decoding of the block at offset:

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

One observation. I came up with the idea used in Fortune, and undoubtedly later discovered that it was already invented. But since I read everywhere, the key point is security, but there is another good point: it is a large random number random number generator, so to speak (in a simplified form). So PRNG, which not only produces a very good sequence (I tested it with Ent and Die Hard), but also allows you to access any subsequence if you know the step number. So is it okay to use Fortuna as a "random access PRNG" in security applications?

EDIT:

In other words, I suggest using Fortuna PRNG as a setting to create a neat AES cipher with random access capability. I read the work of Liskov, Rivest and Wagner, but I could not understand what is the main difference between a cipher in operating mode and an encrypted cipher. They said that they suggested using this approach from the highest level inside the cipher itself, but, for example, in my case, xoring is plain text with a setting, is it a setting or not?

Answer 1

I think you can see how the "improved block ciphers" work and see how the disk encryption problem is solved: Disk encryption theory . Encryption of the entire disk is similar to your problem: the encryption of each sector should be performed independently (you want independent data encryption at different offsets), and yet all this should be safe. There is a lot of work to do. Wikipedia seems to give a good overview.

EDITED adds: Repeat your editing: Yes, you are trying to make the correct encryption algorithm from the AES blog using XORing tweak in clear text. More specifically, you have Enc (T, K, M) = AES (K, f (T) xor M), where AES (K, ...) means encryption of AES with the key K and f (T) is some function (in your case, I assume it is Fortuna). I briefly reviewed the document you mentioned, and as far as I can see, this can show that this method does not create a secure custom block cipher. The idea (based on the definitions from section 2 of the book of Liskov, Rivest, Wagner) is as follows. We have access to the oracle of encryption or random permutation, and we want to inform with whom we interact. We can set the setting T and plaintext M, and we will get the corresponding encrypted text, but we do not know the key that is used. Here's how to find out if we use the AES construct (K, f (T) xor M). Choose any two different values ​​of T, T ', calculate f (T), f (T'). Select any message M and then compute the second message as M '= M xor f (T) xor f (T'). Now ask the cryptographic oracle to encrypt M using tweak T and M 'using tweak T'. If we consider the design in question, the outputs will be identical. If we are dealing with random permutations, the outputs will almost certainly (with a probability of 1-2 ^ -128) be different. This is because both inputs to AES encryption will be the same, so the encrypted texts will also be identical. This would not be the case if we used random permutations, because the probability that both outputs are the same is 2 ^ -128. The bottom line is that setting up xoring for input is probably not a safe method.

The document provides some examples of what they can prove to be a safe design. The simplest is Enc (T, K, M) = AES (K, T xor AES (K, M)). You need two encryption per block, but they confirm the safety of this design. They also mention faster options, but they require additional primitive (almost-xor-universal families of functions).

Answer 2

Although I think your approach is safe enough, I see no advantages over CTR. You have the same problem, which is that you are not introducing true randomness into the ciphertext. Offset is a known systematic input. Despite the fact that it is encrypted with a key, it is still not random.

Another issue is how do you protect FileUniqueKey? Encrypted with password? When using multiple keys there are problems with a number of.

Counter mode adopted for encrypting random access files. Despite the fact that it has all kinds of vulnerabilities, all this is well studied, so the risk is measurable.