Can anyone explain why there is a difference between padding claimed in PKCS7 https://tools.ietf.org/html/rfc2315 Page 22 - which is


02 02

03 03 03 ...

and padding used in TLS 1.2 https://tools.ietf.org/html/rfc5246 Page 24 or http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf Page 1 - which is


01 01

02 02 02

03 03 03 03 ...

Why didn't TLS guys use PKCS7 version of padding?

  • this might be a better fit over at crypto.se – schroeder May 8 '15 at 22:00

The padding isn't different - it actually is PKCS7 padding. The difference is that the data ends with a 1-byte field which expresses the length of the padding. As such, what you're seeing is:

 MAC              Padding          PadLen
 xx xx xx .. xx | 05 05 05 05 05 | 05

This isn't unique to TLS 1.2 - if you dig through the RFCs you'll find that TLS 1.1, TLS 1.0, SSL 3.0 also share this quirk. The reason appears to be legacy compatibility.

The SSL 2.0 specification isn't very clear on how (or what) padding should be applied, but the padding length itself is given in plaintext as a field in the packet. Since this would result in the padding length being distinct from the padding itself, you get a situation where a padding of 03 03 03 has a length record of 03, giving a full value of 03 03 03 03. That being said, SSL 2.0 doesn't use PKCS7-style padding, but instead uses random padding, e.g. A3 89 03 03. By bringing the same padding method to SSL 3.0 (and later to TLS) it was probably seen to be easier to adapt existing code.

So, the answer is: there's no security benefit or detriment to having the extra byte in TLS 1.2, as long as all bytes of the padding are properly checked. The reason it is there is for legacy support and ease of implementing the new protocols on top of older stacks.

  • Wouldn't this ruin some of the messages? Say by some chance len(message + MAC) mod block_size = 0. So we don't need to pad anything. By the same chance the last byte of MAC will be 00. So it would be MAC xx xx xx .. 00 The unpadding then will, by accident, remove last 00, ruining MAC. Or? – Valera P. May 8 '15 at 22:32
  • No. In the case of a message such that len(msg | MAC) % block_size == 0 an entire block of padding is added. – Polynomial May 8 '15 at 22:34
  • Nitpick: SSL3 (at least rfc6101) doesn't specify the content of padding except for the length byte; it's not clear if SSL3 senders all used random, but receivers definitely didn't check hence the recent POODLE attack. 2246+ specifies all bytes repeat the length, and 4346+ specifies receiver check all. They're also explicit you can pad more than the minimum needed to reach a block boundary (as PKCS5/7 do) and can do up to 255+1 (to hide plaintext length) but I've not seen any implementation do so; people who want filler traffic seem to do it at record or app level instead. – dave_thompson_085 May 9 '15 at 4:37
  • @dave_thompson_085 Yes, this is true. However, check section E.2 at the bottom for information about how SSLv3 acts in SSLv2 compatibility mode - it notes that random padding must be used in that case. This indicates that SSLv3 is expected to potentially do something else for its padding in non-legacy mode - I think the idea was to leave it implementation specific or give rise to tying the padding to cipher suite specifications instead. Either way you're correct, hence why I said it's no detriment in TLS 1.2. It was not a good idea in 1.x or 3.0. – Polynomial May 9 '15 at 10:16
  • Not really. E.2 (E.3 in 5246) concerns only RSA encryption of the premaster secret in the handshake for plain-RSA key-exchange, which is different than symmetric encryption. PKCS1-type2 (retronymed RSAES-PKCS1-v1_5) external to and before SSL specified this as mostly random, and correctly so. SSLv3 and later make it slightly less random as a rollback defense, which is only needed when SSLv2 is offered (and agreed); it is related to the key-exchange (only plain-RSA uses PKCS1-type2 at all) but not the rest of the ciphersuite. ... – dave_thompson_085 May 21 '15 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.