How does PKCS7 not lose data?

Question

I'm developing a USB bootloader for an embedded system and one of my requirements is that data transmission over USB should be secure(bear with me, I'm new to encryption). I've decided to encrypt the data with AES, but the data isn't always in nice 16 bytes chunks so I need to pad it. It seems like PKCS7 is the standard method to use when padding data for AES (not to mention it's pretty simple), so I think I'd like to use it.

The problem I have is, I can't understand how PKCS7 doesn't lose data. Let me illustrate with an example:

Imagine a 16 byte buffer to be encrypted whose last character is 0x01. Now imagine a 15 byte buffer to be encrypted...this buffer will be padded with 0x01. After both buffers are encrypted, transmitted, received, and decrypted, how does the receiver tell the difference between the buffer with padding and the buffer whose actual last character is 0x01?

I feel like I'm missing something in the PKCS7 spec. Can anyone help me understand? Thanks in advance.

Answer 1

Yes, you are missing a point. If the data length is a full multiple of the block length (i.e. a multiple of 16 bytes for AES), the padding will append an additional full block (of 0x10 or 16) instead of nothing.

So, we can always recover the length of the padding from the padding itself, since there is no "length 0 padding".

On the downside, the encrypted data is always bigger than the plain text, by at most a full block.

(Similar padding is done for most hash functions, like SHA-1, before the actual hashing processing, so the blocked input to the actual hashing is collision-free – in some cases even a bit more than a full block is appended, since the actually hashed data ends with the original data length).

Answer 2

Assume that the block length is 4 instead of 16 for simplicity.

Here are some unpadded messages (hex):

01
01 02
01 02 03
01 02 03 04

The padded forms of these are:

01 03 03 03
01 02 02 02
01 02 03 01
01 02 03 04 04 04 04 04

Looking at the last byte of the padded form unambiguously tells you how many bytes to remove, and what the values of those bytes must be. If the last byte is 04, there must be 4 bytes to remove and they must all be 04 bytes; anything else indicates message corruption.