Join Log in
Score:1
kelalaka avatar Crypto

On the correctness of the padding example of RFC 5246

in flag
kelalaka

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 of01,02,...,or,16 for a 16-byte sized block cipher. While reading

I've seen that they gave an example as;

The second block contains the remaining 9 HMAC bytes and 7 bytes 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?

41
0 + 0
tls
kelalaka avatar
in flag
kelalaka
Note that I'm not considering SSLv3 padding where the last byte denotes the number of padding bytes and the rest of the padding can take any value.
0
Reply
dave_thompson_085 avatar
cn flag
dave_thompson_085
Crossdupe https://security.stackexchange.com/questions/161153/rfc-5246-tls-1-2-padding-example-mistake and https://security.stackexchange.com/questions/88839/pkcs7-vs-tls-1-2-padding
1
Reply
Score:3
Gilles 'SO- stop being evil' avatar Crypto
cn flag
Gilles 'SO- stop being evil'

The padding used for CBC cipher suites in SSLv3 through TLS 1.2 is not PKCS#5/PKCS#7 padding. It's the padding used in SSL/TLS, which I haven't seen anywhere else.

The padding in TLS 1.0, TLS 1.1 and TLS 1.2 can be from 1 to 256 bytes, so it can fill multiple blocks. In the predecessor protocol SSL 3.0, it must complete exactly one block. In all versions, the last byte must be the length of the padding, excluding that last byte. The preceding bytes can take any value in SSL 3.0, and must be the padding length in TLS 1.0 through 1.2. For a block cipher with $B$-byte blocks:

Specification Total length Blocks Content
PKCS#7 $n \in [1, B]$ bytes $1$ $(n, \ldots, n)$
SSL 3.0 $n \in [1, B]$ bytes $1$ $(?, \ldots, ?, (n-1))$
TLS 1.0–1.2 $n \in [1, 256]$ bytes $1$ to $\lceil 256/B \rceil$ $((n-1), \ldots, (n-1))$

As you can see, PKCS#7 fills the padding with the total padding length, whereas TLS 1.0–1.2 fills the padding with the total padding length minus one. The reason for this seemingly odd choice is that it's an adaptation of the SSL 3.0 padding, in which the last byte is a length byte which is not including in what the SSL specification calls the “padding”, and the “padding” proper can have arbitrary content.

The examples you cite from RFC 5246 and from Merget et al. are correct. If adding 7 bytes brings the plaintext to a multiple of the block size, then 06 06 06 06 06 06 06 is a possible TLS padding (as are 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16, etc.).

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.