Why is triple DES is calculated in encrypt decrypt encrypt mode? Why a decrypt in the middle? And isn't decrypt = encrypt since DES in a symmetric cipher?
It is for backwards compatibility with normal DES. If you use the same key for the first two operations, they cancel out and you are left with a ciphertext encrypted under a single DES key.
Decrypt is not the same as encrypt. Symmetric refers to the fact that both use the same key but the actual steps are effectively reversed.
Why in EDE decrypt is in the middle? -
Initialy you have a plaintext so you can only Encrypt it. So you have to start with Encryption. -so first E in EDE
After first Encryption you’ve got a ciphertext - you can only Decrypt it - So we get second D in the middle of EDE
Then with the same logic we having final E
Additional security of triple DES(by using longer key) is achieved by using different keys in all these enc/dec sequence. So the triple DES long key (168-bit) is actually a combination of all these standard DES 56-bit keys.
But for compatibility reasons it is left opportunity to use the same 56 bit key in EDE sequence - this makes triple DES to work as a simple DES
Being a "symmetric" means that both the encryption and decryption KEYS are the same (or easily computable from the other), not the algorithm. It does not mean that encryption = decryption. However in the case of DES which is a fiestel cipher which has 16 rounds - encryption is actually the same process as decryption - this actually helps to implement the cipher on hardware easily, except in DES there is a key schedule which means that a different sub-key is used at each round so running it one way becomes encryption (keys 1 ~ 16) and running it the other way decryption (keys 16 ~ 1).
There are two configurations of 3-DES EDE (encrypt decrypt encrypt) and EEE and 3 choices of key schemes, 1 key 2 key (2TDEA) and 3 key (3TDEA). Also note that the design of DES is also based around thinking about the use of custom hardware for efficiency reasons.
3-DES uses EDE such that you can enter the the same key three times which actually will be then the same as just using DES with that one key - this is the backwards compatability. This follows through to using three separate keys as you may implement the 3-DES algorithm in hardware (or be unable to change the cipher mode) wanting three key triple DES and also backwards compatibility. For example an implementation may be that the user sets the key in a settings store or database if wanting a 3key DES would use the key AAAAAAAAAAAAAABBBBBBBBBBBBBBCCCCCCCCCCCCCC but if wanting to send a message to a resource that only had DES implemented then it would use the key AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA the programmer may have hard coded in the 3-DES EDE. Also for 2 key 3-DES the user may enter AAAAAAAAAAAAAABBBBBBBBBBBBBBAAAAAAAAAAAAAA as the key. The function may simply be encrypt(messsage, key) rather than encrypt(message, key1, key2, key3, configuration). This is the reason why it is standard to use EDE for 3-DES, the key choice 1/2/3 is relatively separate from the actual encryption implementation. From a security standpoint using Encrypt Encrypt or Encrypt Decrypt is the same as we mentioned above that the difference is simply the re-ordering of the sub-keys used, as key 1 and key 2 are different anyway. It should also be noted that DES keys required 8 partiy bits, so a key is actually 64bits long and one bit of the parity is attributed to each byte, but the actual visiblity of this will vary with the implementation. The reason why 2key 3-DES does k1, k2, k1 is that. If using k1,k1,k2 in EDE mode you would effectively only be encrypting via k2 and also if you encrypt using k1,k1,k2 in EEE because of the fiestel cipher design you creating it to be susceptible to some analysis attacks - this goes for any encryption you should not encrypt twice using the same key and expect it to be secure.
Double DES is actually different to 2 key 3-DES, double DES is susceptible to meet in the middle attacks where you pre-compute the DES encryption of a chosen plaintext and store this using 2^56 x 64 bits of space, you then have to get the system to encrypt the chosen plain text for you and you decrypt it until it matches one of the stored values, you then have both candidate keys, using another 1/2 plaintext/cipher text pairs you can then test these keys to see if they are actually correct. This is a space time tade-off and said to effectivly reduce the keysize to 56 bits + database search time. However this is not true of 2 key 3-DES because we encrypt with key 1 and then key 2 and then again with key 1, to meet in the middle you would have to pre-compute both key 1 and key 2's encryption anyway, not decreasing the time required. In this case there is an attack on 2 key 3-DES that requires 2^56 CHOSEN plain-texts/cipher-text pairs and reduces the key to 56bits - however plain-texts/cipher-text pairs may be very difficult depending on the access to the system protocol. As an unauthorized user you may not get to encrypt messages or be relying on randomly generated values. Also another attack reduces the security to 2^(120-n) if you have n KNOWN pairs. So the practicality of these attacks is in question. I believe this is suggested in the reference below. I believe 3 key 3-DES is still susceptible to Meet in the Middle attacks regardless of using EDE or EEE, this effectivly reducing its security to 112 bits. The reason for this is you can calculate the encryption of a chosen plaintext on key 1 and store these using the same amount of space as the double des attack, the remaining 112 bits of the key you still have to exhaustive search, but this does reduce the time required to calculate the key on-line.
Because of these vulnerabilities it is better to use 3TDEA over 2TDEA, so I doubt there would be many new applications sing 2TDEA (I believe NIST may be advising against using it). However the only reasons I can think of using 2 key is that the key size is smaller, so this is space efficiency. Originally before the recent attacks on 2-key, 2-key and 3-key were though to be of similar security ~112bits for both - so from the standpoint of an implementer "why waste time with the extra key if it's the same"? Or maybe you were migrating to or from a different algorithm that used 128bits (remember this is the actual size of a 2TDEA key including the parity bits) and did not want to or it was infeasible to change keys - or the key generation algorithm for the previous system was 128bits so you also don't need to change the generator - this is just an idea.
C. van Oorschot and Michael J. Wiener. 1991. A known-plaintext attack on two-key triple encryption. In Proceedings of the workshop on the theory and application of cryptographic techniques on Advances in cryptology (EUROCRYPT '90), Ivan Bjerre Damg\ård (Ed.). Springer-Verlag New York, Inc., New York, NY, USA, 318-325.
(Reason for writing this - I have an exam on this soon, hope this covers all and any corrections welcome).