# Can AES decryption be used as encryption?

Definition

• E: AES encryption
• D: AES decryption
• x: plain text
• y: encrypted text
• k: key

In original AES cipher,

• encryption: y = E(x, k)
• decryption: x = D(y, k)

Then I define the "reverse AES cipher" as below.

• encryption: y = D(x, k)
• decryption: x = E(y, k)

Is "reverse AES cipher" safe as original AES?
or, is safe but the strength is not simply comparable with AES?
or, is not safe?

Or, do anyone know any ciphers that can be used as above and are safe and practical as AES?

-

## migrated from stackoverflow.comAug 10 '13 at 20:49

This question came from our site for professional and enthusiast programmers.

Note that normally an encryption routine will pad your data to make it of the right size, while a decryption routine will check that the padding is "correct" and remove it. – xanatos Aug 10 '13 at 6:27
I am pretty sure it is secure, but I flagged it to be transferred to this site. I could not find a decisive answer on this site or the internet. – Maarten Bodewes Aug 10 '13 at 21:02
@xanatos I presume we are talking here about a single block encrypt, otherwise the question should have contained a mode of operation and padding mode. – Maarten Bodewes Aug 10 '13 at 21:03
I'd like to point out that the correctness ( E(D(m,k),k)=m ∀m ) of your construction is not all that obvious; there are cryptosystems where this would not work. The reason correctness is given here is that blockciphers are permutations and as such bijective. Therefore every left inverse is also a right inverse. – Perseids Aug 11 '13 at 19:50

First, I'll assume we're talking about encrypting/decrypting exactly 128 bits of data, i.e. the block size of AES. Otherwise, you'll need to specify a mode of operation — and if your data's length isn't a multiple of the block size, well, that'll be more difficult to deal with. So, I'll assume we're working with a single block. (If you are using a mode of operation, the below doesn't apply; see the other answer(s) for more details.)

AES models a theoretical construction called a pseudorandom permutation (PRP). Essentially, this means that if we set up a game where we give a polynomial-time-limited adversary access to either (1) an oracle computing a truly-random permutation or (2) an oracle computing the pseudorandom permutation (with a randomly chosen key), the adversary cannot determine which they were given access to with any non-negligible advantage. (They can always guess one or the other, so they have a 50% chance of guessing right; what the PRP security requirement states is that they can't get any non-negligible chance over that 50%.)

There is a stronger notion of a PRP called a strong pseudorandom permutation. In the strong PRP game, the adversary is given access not just to an oracle computing the permutation in question: they're also given access to the inverse of the permutation. In terms of block ciphers, this means that instead of getting access to just an encryption oracle, they would also get access to a decryption oracle.

As far as we know, AES is indeed a strong PRP, so for single blocks, swapping the encryption and decryption functions should be fine. You could then use this in other block cipher modes of operation, for instance.

-
+1 for mentioning all the necessary related concepts. – DarkWanderer Aug 14 '13 at 11:32

Well, it turns out that depends on what you mean by "the AES cipher".

If you are talking about the block cipher primitive, that is, if you define an alternate block cipher by taking AES, and swapping the 'encrypt' and 'decrypt' directions, well, that alternative block cipher is precisely as strong as AES. It can be used in any mode of operation we would normally use with AES, and work just as well. In fact, if we had any evidence that your block cipher had any specific weakness, that would immediately translate into a weakness within AES.

However, if you're talking about AES in a specific mode of operation, and use the 'decrypt' mode to encrypt, you may run into unexpected issues, depending on the mode (or it might not work at all; it won't for any authenticated-encryption mode). For CBC mode, yes, you can run into issues (and see below for the extended discussion); for CTR (counter) mode, you don't (in fact, encrypt and decrypt are the exact same operation, so swapping the two don't really change anything).

Now, for the discussion of CBC mode and the weakness you can run into:

CBC mode during encryption is immune to chosen plaintext attacks (assuming that the IV is selected randomly); that is, if the attacker specifies the plaintext, and then examines the encrypted ciphertext, that (with high probability) gives him no information on any other ciphertext he might have. In fact, even if you guesses the exact plaintext that his ciphertext under attack might be, and asks that to be encrypted, the resulting ciphertext will be unrelated (with high probability) to the ciphertext he already has. This is because the IV acts as a randomizer on the entire message.

This is not true for CBC mode in decrypt mode; the IV affects only the first block; hence (in this model) if the attacker submits the guessed plaintext, that will be exactly the same ciphertext (except for possibly the first block); hence CBC mode decryption is not secure in this model.

Side note (getting off topic, but this is the answer to a rather obvious question), this observation does not affect CBC mode decryption as it is normally used, because we add a Message Authentication Code to the message; if the attacker submits his own ciphertext, the MAC will fail, and so he doesn't learn anything. However, if you're using CBC mode decryption to "encrypt", we don't have a MAC.

-