I'm working on an application where AES-256-ECB has been specified. It has been asked that a fixed pattern is included at the end of the message to allow the decoding end to ensure the decryption has been successful. I was thinking to use a fixed padding value, and add 16-bytes of padding if no padding was originally required.

I know a better way of doing this is to use an authentication code (and to use AES in a different mode) but the client does not want to add extra complexity.

Will the use of a fixed pattern at the end of the message compromise the AES-ECB encryption if an attacker guessed the presence of the pattern? (I'm remembering what happened in the Imitation Game movie!)

Update: features of the data to be encoded mean the same encoded data will not be repeated.

Update: I appreciate the advice about other modes, and have raised this myself. But for whatever reason ECB is the mode of choice.

  • If you are using ECB you already have an issue. ECB should be avoided as an AES mode as similar blocks will result in the same cipher text. Apr 29, 2016 at 10:07
  • Even if you do not encode the exact same data you will have a problem with using ECB, if there is any form of consistency between the data (like a format or layout or your self described padding) it will remain possible for an attacker to deduce the encryption process making it useless. I strongly urge you not to use ECB since it has glaring flaws, and instead opt to use a safer mode of AES.
    – MSB
    Apr 29, 2016 at 12:44
  • 2
    Would you please let us know if this is an application that would be used by consumers or by a company that protects consumer information, so we can avoid it like the plague Apr 30, 2016 at 2:25
  • @Nigel Smith I hope I successfully answered your question, if there are still parts that are unclear I would be more than willing to clear them up. If you would like further help with the details and implementation of any of the other modes I would also be more than willing to help you out if you post it in a separate question. if my answer has solved your question please consider accepting it by clicking the check-mark.
    – MSB
    Apr 30, 2016 at 12:34

1 Answer 1


To answer your question: Yes. You are facing two problems:

1) ECB is inherently unsafe to use and is only meant to be used as a building block for more safe operations. ECB mode produces the same output for the same input each time so it is extremely deterministic.

2) Because of the properties mentioned in 1 it will become trivial for an attack to determine what you exact padding is when he gathers a bunch of texts.

You should really consider using a more complex operation mode. I strongly suggest that you use CBC (Cipher Block Chianing) or any of the other more secure modes (OFB, CFB, CTR) <- look these up if you have to.

EDIT: I made you a list down below that references wikipedia and also explains that ECB should not be used:


The simplest of the encryption modes is the Electronic Codebook (ECB) mode. The message is divided into blocks, and each block is encrypted separately. The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.


In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point. To make each message unique, an initialization vector must be used in the first block. CBC has been the most commonly used mode of operation. Its main drawbacks are that encryption is sequential (i.e., it cannot be parallelized), and that the message must be padded to a multiple of the cipher block size. One way to handle this last issue is through the method known as ciphertext stealing. Note that a one-bit change in a plaintext or IV affects all following ciphertext blocks.


The Cipher Feedback (CFB) mode, a close relative of CBC, makes a block cipher into a self-synchronizing stream cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC encryption performed in reverse.


The Output Feedback (OFB) mode makes a block cipher into a synchronous stream cipher. It generates keystream blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property allows many error correcting codes to function normally even when applied before encryption.


Like OFB, Counter mode turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a "counter". The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual increment-by-one counter is the simplest and most popular.

  • The only risk if you go by just his question (not asked if ECB is secure) is that an attacker may be able to detect that he is using the ECB mode due to the similar padding.
    – BMC
    May 29, 2016 at 20:45
  • true, I did find it relevant to mention though since it seems the OP is planning to use this in a production environment. In turn I also used this notion to directly answer his question and explain that it would be trivial to determine the padding. The reverse is also true but would be true in general for ECB.
    – MSB
    May 30, 2016 at 10:01
  • Absolutely. Was just mentioning it below in case he wanted just the risk point.
    – BMC
    May 30, 2016 at 10:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .