Is there any difference except speed and key and block size from user's point of view?

Or does AES have something that ideal block cipher doesn't have?

  • 2
    $\begingroup$ I think this question is too broad. Yes, AES was completely different from previous ciphers in many respects. Can you be more specific? $\endgroup$
    – mikeazo
    May 5, 2013 at 1:49
  • $\begingroup$ Is there any difference from user's point of view? $\endgroup$ May 5, 2013 at 7:53

2 Answers 2


From a user's point of view, AES improves on DES and 3DES in at least two important aspects beyond speed and key length:

  1. AES is a 128-bit block cipher, which makes it more secure for huge volume of data than a 64-bit block cipher is. For example, any 64-bit block cipher in CBC mode is vulnerable to a simple distinguisher attack: the adversary has a chance to recognize plaintext with all identical blocks (e.g. unused portion of a file), because the corresponding ciphertext is more unlikely to contain collisions than it is for random plaintext. That makes 3DES-CBC quite practically unsafe for 32 GiB enciphered; for 8 MiB enciphered, the advantage is already like $2^{-25}$ (fixed).
  2. AES does not have the complementation property of DES (and 3DES), which is that $\forall K, \forall X, \overline{\operatorname{DES}(K,X)}= \operatorname{DES}(\overline K,\overline X)$; that property, while occasionally useful, is undesirable in some protocols, and from a theoretical standpoint makes DES and 3DES trivially distinguishable from a random encryption oracle.
  • 1
    $\begingroup$ 1. Is only CBC vulnerable? Is there a way to get rid of this limitation? $\endgroup$ May 7, 2013 at 15:35
  • $\begingroup$ @Smit Johnth: Other common operating modes (CFB, OFB, CTR) have the same vulnerability: constant plaintext is correlated to lower odds of collision between ciphertext blocks, and that may be a concern for (nowadays) practical data sizes and 64-bit block ciphers. The best fix is to use a wider block cipher (kludges are possible with CBC and CFB; e.g. add the block index to each plaintext bock). $\endgroup$
    – fgrieu
    May 7, 2013 at 20:57

From a users point of view, encryption algorithms tend to look alike. You feed the key and plaintext (and preferably a random initialization value) to the encryption function, and it produces the ciphertext.

See e.g. the example code for different algorithms from the pycrypto toolkit:


from Crypto.Cipher import DES3
from Crypto import Random

key = b'Sixteen byte key'
iv = Random.new().read(DES3.block_size)
cipher = DES3.new(key, DES3.MODE_OFB, iv)
plaintext = b'sona si latine loqueris '
msg = iv + cipher.encrypt(plaintext)


from Crypto.Cipher import AES
from Crypto import Random

key = b'Sixteen byte key'
iv = Random.new().read(AES.block_size)
cipher = AES.new(key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')

From a usage view, even a stream cipher isn't that different;


from Crypto.Cipher import ARC4
from Crypto.Hash import SHA
from Crypto import Random

key = b'Very long and confidential key'
nonce = Random.new().read(16)
tempkey = SHA.new(key+nonce).digest()
cipher = ARC4.new(tempkey)
msg = nonce + cipher.encrypt(b'Open the pod bay doors, HAL')

A difference from a security point of view is that from the set of ciphers that aren't considered broken yet Rijndael/AES has received a lot of scrutiny both during the selection process and afterwards. Possibly significantly more than other published algorithms that weren't part of the competition.

  • $\begingroup$ RC4 isn't a good comparison since it's a stream cipher. $\endgroup$ May 5, 2013 at 13:34
  • 1
    $\begingroup$ @SmitJohnth The distinction blurs as you move to a higher level. Ultimately most cryptography libraries provide a unified interface to all encryption algorithms regardless of the cipher being used, asking for the plaintext, IV, and key, and returning the ciphertext, and handling all the differences internally, away from the user's concern. The only difference with stream ciphers is you need some more work as they typically don't have built-in IV mechanisms and sometimes not even key schedules, but that can be abstracted away as well. $\endgroup$
    – Thomas
    May 5, 2013 at 14:21
  • $\begingroup$ Actually, i meant raw cipher, without modes of operations. Read "user" as "non-cryptographer". $\endgroup$ May 5, 2013 at 14:41
  • 1
    $\begingroup$ @SmitJohnth But a "non-cryptographer" would not use raw ciphers. $\endgroup$
    – Thomas
    May 5, 2013 at 15:11
  • $\begingroup$ @SmitJohnth If you want to encrypt more than one block with a block cipher, you need to use a mode of operation. Both block ciphers in the example above require a mode argument in their new() methods. $\endgroup$ May 6, 2013 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.