# Is there any fundamental difference between the block cipher operations encryption and decryption?

Is there any fundamental reason to designate one direction of a block cipher as "encryption" and the other "decryption"? Or are these arbitrary choices? Or perhaps practical decisions for specific cipher designs?

Put another way, if the designers of DES or AES had chosen to label what are known as "encryption" as "decryption" and vice versa, would the world be any different?

Is it that there is an indistinguishability proof/argument for $$E_k(m0)$$ vs. $$E_k(m1)$$ while there is no such for $$D_k(m0)$$ vs. $$D_k(m1)$$?

Or perhaps $$E$$ has different performance characteristics than $$D$$, and some assumption has been made about the relative frequency of one operation vs. the other?

e.g. for AES encryption is apparently more efficient than decryption, and some assumption has been made that it's more important to be able to encrypt quickly than to decrypt (not sure why that should be so...)

• No, we just want both of them efficient. The small difference is there due to the design. Dec 1 '21 at 18:04
• @kelalaka can you clarify what you mean by "due to the design" - is this a deliberate design choice? Or an accidental outcome of the way the AES cipher is designed? Dec 1 '21 at 18:06
• With a little search in out site; AES encryption takes more time to decrypt than encrypt Dec 1 '21 at 18:14
• @kelalaka Would you like to post an answer including the quote from the discussion you referenced "MACs only need the encryption primitive, and even some encryption/decryption algorithms (CTR, EAX) only use the encryption primitive of the underlying block cipher. So the Rijndael algorithm was optimised for encryption speed over decryption speed". Except that that statement is made without any reference, so it's not clear if it's fact or opinion Dec 1 '21 at 18:20
• It would be very strange for a (keyed) pseudo random permutation (PRP) to be secure in one direction and not in the other. Dec 1 '21 at 21:18

From a cryptanalytic point of view, there is only difference in the labelling of the attack assumptions. All modern block ciphers are designed to be secure against both CPA (chosen plaintext attacks) and CCA (chosen ciphertext attacks). A CPA attack on the encryption function is a CCA attack on the decryption function and vice-versa.

There's an argument to make the encryption function the quicker of the two as certain modes (Cipher Block Chaining) are parallelisable for the decryptor but not for the encryptor. Faster encryption now balances the clock time for the operations better. Other modes do not require decryption at all (Counter modes, Output Feedback mode). Block cipher designers like to produce designs that work well for all modes and so encryption faster than decryption is a legitimate, but not compulsory, design decision.

• Fun fact: it is possible to implement CBC-mode encryption using the block cipher in the decrypt direction (you process the message in reverse order, working with the last block first, doing a CFB-style operation - still not parallelizable); hence, for CBC mode, it might make sense to make the 'decrypt' operation the more efficient one :-) Dec 2 '21 at 14:47
• @poncho I'm not sure if I fully follow what you're describing. Is it written down somewhere? Dec 2 '21 at 15:49
• Someone suggested it a few years ago here on crypto.stackexchange. The idea is fairly simple; assuming you have plaintext blocks $P_0, P_1, ..., P_n$, you select a random final ciphertext block $C_n$, and iteratively compute $C_{i-1} = P_i \oplus D_k( C_i )$; the final $C_{-1}$ value is the IV to send with the message. It is easy to see that if $C_n$ was selected uniformly at random, it generates ciphertexts/IVs with the same probability distribution as the normal CBC-mode implementation with a uniformly selected IV (and hence is equally secure) Dec 2 '21 at 17:07

There's no fundamental difference. We can even swap encryption and decryption functions, and nothing will happen:

$$c = D_k(m), m = E_k(c).$$

Of course, depending on cipher and implementation, one direction may be faster than the other.