Skip to main content
added 437 characters in body
Source Link
dr jimbob
  • 1.1k
  • 7
  • 12

If you are talking about the AES block cipher acting on a singleone block message, then yes, with K being the actual 128/192/256 bit-key. For a given key, the encryption E(message, key) and decryption D(ciphertext, key) functions are perfect inverses of each other. You will always have both E(D(m,K),K) = m and D(E(m,K),K) = m by construction for any block cipher encryption/decryption functions operating on a one-block message m (for AES one block = 128-bits = 16 bytes).

That said in practice, if you use some well-written tool in a secure mode (like openssl aes-[128|192|256]-cbc) that internally uses AES as the block cipher for encryption/decryption this may notprobably will NOT work, if you simply feed your tool a plain text message, and ask it to decrypt said message with your key.

This is because your tool that uses AES as your block cipher will make various assumptions for you and does more than just apply AES to each block. Why? Specifically:

  1. The tool will likely add proper padding to your message before encrypting it and will fail to decrypt if you are attempting to decrypt something that wasn't properly padded. (Without proper padding their are attacks against multi-block AES encrypted messages).
  2. On encryption, the tool may prepend the ciphertext with a block of a random initialization vector (IV); on decryption doesn't attempt to decrypt the zero-th block assumed to be an IV. (Without an initialization vector, an eavesdropper can detect when similar starting messages are being sent and potentially tamper with them).
  3. The tool also may include some sort of MAC to verify the data wasn't tampered with that will fail if you attempt to decrypt a plaintext message (thatas the plaintext message would not have a valid MAC that allows decryption to proceed).

If you are talking about the AES block cipher acting on a single block, then yes, with K being the actual 128/192/256 bit-key. For a given key, the encryption and decryption functions are perfect inverses of each other. You will always have both E(D(m,K),K) = m and D(E(m,K),K) = m by construction for any block cipher encryption/decryption functions.

That said in practice, if you use some tool (like openssl aes-[128|192|256]-cbc) that uses AES as the block cipher for encryption/decryption this may not work, if you simply feed your tool a plain text message, ask it to decrypt said message with your key.

This is because your tool that uses AES as your block cipher will make various assumptions for you and does more than just apply AES to each block. Why?

  1. The tool will likely add proper padding to your message before encrypting it and will fail to decrypt if you are attempting to decrypt something that wasn't properly padded.
  2. On encryption, the tool may prepend the ciphertext with a block of a random initialization vector (IV); on decryption doesn't attempt to decrypt the zero-th block assumed to be an IV.
  3. The tool also may include some sort of MAC to verify the data wasn't tampered with that will fail if you attempt to decrypt a plaintext message (that would not have a MAC that allows decryption to proceed).

If you are talking about the AES block cipher acting on a one block message, then yes, with K being the actual 128/192/256 bit-key. For a given key, the encryption E(message, key) and decryption D(ciphertext, key) functions are perfect inverses of each other. You will always have both E(D(m,K),K) = m and D(E(m,K),K) = m by construction for any block cipher encryption/decryption functions operating on a one-block message m (for AES one block = 128-bits = 16 bytes).

That said in practice, if you use some well-written tool in a secure mode (like openssl aes-[128|192|256]-cbc) that internally uses AES as the block cipher for encryption/decryption this probably will NOT work, if you simply feed your tool a plain text message and ask it to decrypt said message with your key.

This is because your tool that uses AES as your block cipher will make various assumptions for you and does more than just apply AES to each block. Specifically:

  1. The tool will likely add proper padding to your message before encrypting it and will fail to decrypt if you are attempting to decrypt something that wasn't properly padded. (Without proper padding their are attacks against multi-block AES encrypted messages).
  2. On encryption, the tool may prepend the ciphertext with a block of a random initialization vector (IV); on decryption doesn't attempt to decrypt the zero-th block assumed to be an IV. (Without an initialization vector, an eavesdropper can detect when similar starting messages are being sent and potentially tamper with them).
  3. The tool also may include some sort of MAC to verify the data wasn't tampered with that will fail if you attempt to decrypt a plaintext message (as the plaintext message would not have a valid MAC that allows decryption to proceed).
Post Migrated Here from security.stackexchange.com (revisions)
Source Link
dr jimbob
  • 1.1k
  • 7
  • 12

If you are talking about the AES block cipher acting on a single block, then yes, with K being the actual 128/192/256 bit-key. For a given key, the encryption and decryption functions are perfect inverses of each other. You will always have both E(D(m,K),K) = m and D(E(m,K),K) = m by construction for any block cipher encryption/decryption functions.

That said in practice, if you use some tool (like openssl aes-[128|192|256]-cbc) that uses AES as the block cipher for encryption/decryption this may not work, if you simply feed your tool a plain text message, ask it to decrypt said message with your key.

This is because your tool that uses AES as your block cipher will make various assumptions for you and does more than just apply AES to each block. Why?

  1. The tool will likely add proper padding to your message before encrypting it and will fail to decrypt if you are attempting to decrypt something that wasn't properly padded.
  2. On encryption, the tool may prepend the ciphertext with a block of a random initialization vector (IV); on decryption doesn't attempt to decrypt the zero-th block assumed to be an IV.
  3. The tool also may include some sort of MAC to verify the data wasn't tampered with that will fail if you attempt to decrypt a plaintext message (that would not have a MAC that allows decryption to proceed).