Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
Definition
In original AES cipher,
Then I define the "reverse AES cipher" as below.
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?
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.
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.
