The PKCS#7 padding is defined in rfc5652#section-6.3
Some content-encryption algorithms assume the input length is a multiple of k octets, where k is greater than one. For such algorithms, the input shall be padded at the trailing end with k-(lth mod k) octets all having value k-(lth mod k), where lth is the length of the input. In other words, the input is padded at the trailing end with one of the following strings:
01 -- if lth mod k = k-1 02 02 -- if lth mod k = k-2 . . . k k ... k k -- if lth mod k = 0
As we can see, the padding bytes can contain a series of
16 for a 16-byte sized block cipher. While reading
- 2019 Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities by Merget et al.
I've seen that they gave an example as;
The second block contains the remaining 9 HMAC bytes and
7bytes of padding
0x06, see Figure 1. Note that the encryptor can also choose longer padding and append 23, 39, ...or 247 padding bytes (while setting the value of the padding bytes accordingly).
This is not PKCS#7 padding. So, I've looked at TLS 1.2's RFC 5246 and see almost the same pattern;
If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC.
To be compatible with PKCS#7 padding, the above should be ( couldn't see an errata)
If the padding length were the minimum necessary, 7, the padding would be 7 bytes, each containing the value 7. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 07 07 07 07 07 07 07, where xx is the last octet of the MAC.
and the article has a mistake there, too.
As far as I know, these two resources are incorrect. Is there something that I've missed about the different designs/usages of PKCS#7 padding rules?