Does use of fixed padding pattern compromise AES-ECB

Question

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.

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:

ECB:

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.

CBC:

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.

CFB:

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.

OFB:

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.

CTR:

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.