# Swapping Key and IV in AES? Safe?

I have an application where I want to be able to send an encrypted file, and then mete out "keys" that allow the receipient to decrypt the file from a certain point to the end of the file. Actually, it's from a certain point to the beginning, and I'm doing the above by reversing the file.

Looking at AES (and thus Rijandel) and all of the available block modes, it needs the key to decrypt every block, and so releasing this would allow the receipient to decrypt the entire file. Not useable.

However, if I was to make the Key public, much like the IV or a Salt is usually public, and instead mete out the IV necessary to decrypt block N through the end, then that would give me the functionality I need, since theoretically the IV in a mid-stream block does not let you derive the IV for previous blocks, but only subsequent blocks.

So, the question is, how less secure is AES if I switch the Key and IV around as inputs to the block cipher?

-
What mode of operation do you want AES to use, or is that part of the question? –  B-Con Aug 5 '13 at 20:55
At what granularity do you need your irreversibility? 1 byte? 16 bytes? 1 KB? Larger blocks increase performance, but it's possible to go backwards to the beginning of the block. –  CodesInChaos Aug 6 '13 at 7:14

For all standard modes, AES isn't secure at all if you reveal the key; even if you keep the IV hidden.

Exactly how this works out varies between modes; for CBC mode, the attacker will be able to decrypt the entire text except for the first block (well, last block because of your reversing the file), even if you didn't give him an IV. The same goes for CFB mode.

As for OFB and CTR modes, the 'IV update' function is reversible and independent of the message; hence revealing any intermediate IV will allow the attacker to decrypt the entire message.

What you want is unusual (at least, I never heard of the requirement before), and it's not surprising the existing modes can't handle it.

One idea which might work out is a varient of OFB mode using SHA-256 (for example), that is:

$IV_{i} = SHA256(IV_{i-1})$

$C_i = P_i \oplus upper128(IV_i)$

where $P_i$, $C_i$ are the i-th plaintext and ciphertext blocks (128 bits), and $upper128$ extracts 128 bits of its input.

The idea is:

• The IV update function is noninvertible, hence the attacker does not have immediate access to previous states

• Even if the attacker has a guess for the previous plaintext block, he cannot validate it. That is, if he is given $IV_i$, knows $C_{i-1}$ and has a guess for $P_{i-1}$, he can't determine if his guess is correct; that guess tells him what 128 bits of $IV_{i-1}$ would be, but $IV_{i-1}$ has 128 bits he isn't given, and that's too much to search over).

Now, this is nonstandard, nonvetted and slow compared to AES-based transforms. However, it might address the problem you're looking at.

-
I think their idea might work in PCBC mode, since the preceding plaintext block is required to decrypt a ciphertext block. –  Reid Aug 5 '13 at 21:06
That's not true, PCBC can be run backwords; $P_{i-1} = D_k(C_i) \oplus P_i \oplus C_{i-1}$ –  poncho Aug 5 '13 at 21:11
Oh, right. For some reason I was thinking under the assumption that they didn't have $P_i$, but if they don't have that then the idea doesn't work anyway. I believe revealing the key but not the IV wouldn't compromise the confidentiality of PCBC, with the interesting property that revealing a single plaintext block would allow you to decrypt all the others... But I haven't thought about it too extensively, since that's sort of an odd situation. –  Reid Aug 5 '13 at 21:24