Cryptography particular block length valid message

Question

I am new at cryptography and start to learn some terms. I just saw an question in the book and didn't got a clue about this question. Could someone can explain me the answer of this question? Because all of the questions seems to be fine for me.

Assuming the block length is 8 bytes (L = 8) Which of the following is/are are valid coded messages?

1. 0x01 FF 52 18 04 04 04 04
2. 0x01 FF 04 04 04 04 04 04
3. 0x09 09 09 09 09 09 09 09
4. 0x01 02 03 04 05 06 07 08
5. 0x01 02 03 04 05 06 07 01

Answer 1

The trick with PKCS#5 padding (or the nearly equivalent PKCS#7 padding) is that it ends with a byte that indicates the number of padding bytes that was added to the message. You'd add $1$ to $n$ bytes to the message, where $n$ is the block size (formally $n=8$ in PKCS#5, $n\le255$ in PKCS#7). The end result is a full block of plaintext so that it can be encrypted using ECB or (P)CBC, without resorting to ciphertext stealing.

To check the validity of the padded plaintext as prescribed by PKCS#5 (6.1.2 §5), first take the final byte value $v$ and check if it is in the range $1$ to $n$ inclusive. Then check if the $v-1$ bytes before that final byte also have this value $v$. During decryption those bytes would be removed leaving you with the message. That message may well end with one or more bytes with the same value.

Note that the above checks allow for padding oracle attacks, and thus should not be performed if the integrity of the ciphertext hasn't been established by the receiving party. If the plaintext size is known in advance, then the checks and unpadding can be skipped altogether. Alternatively, when and if it becomes necessary to remove the padding, we can take the last byte $v$, and remove the $((n-1+v)\bmod n)+1$ last bytes. When $n\ne8$ this deviates neither from PKCS#5 (since formally it applies to $n=8$ only) nor from PKCS#7 (since that leaves the padding removal unspecified). This avoids the padding oracle, but later tests of the plaintext can still be exploitable.

Beware that there is also a padding mode from the (withdrawn) ISO 10126 standard that allows for padding with a byte of any value before the final byte. Otherwise it is compatible with PKCS#5/7, including the alternative padding check of the above paragraph.