6
$\begingroup$

I'm trying to understand the SSL Poodle Attack and I'm wondering why the last block of a CBC Record can be full of padding? Wouldn't that mean that the useful data was already a multiple of the key size?

Maybe I'm misunderstanding something else here, as it would seem like you can pad by any number of full blocks of padding. Just don't see why an SSL Library would do that.

Thanks!

Improve this question
$\endgroup$
3
  • 3
    $\begingroup$ How will you know that there is no padding? It must always be padded otherwise it is not reversible. $\endgroup$
    – LightBit
    Commented Feb 25, 2015 at 17:55
  • $\begingroup$ That's what my only explanation was. The last byte must be the size of the padding. It's just this text never explains that, and makes it seems like the last byte might not necessarily be the size of the padding. Just a crypto-noob :). $\endgroup$
    – Eugene K
    Commented Feb 25, 2015 at 17:57
  • $\begingroup$ Related question: What prevents a padding standard to cause a data loss? $\endgroup$
    – CodesInChaos
    Commented Mar 22, 2016 at 10:18

2 Answers 2

Reset to default
4
$\begingroup$

SSL padding always pads, using 1..blocksize bytes (8 bytes for triple DES, 16 for AES). This padding makes it deterministic independently of the value of the plaintext. It's a padding mode similar to ISO 10126 (only the last padding byte is one less).

Other padding values - such as the zero padding performed by PHP's mcrypt library - are also deterministic, but they require the plaintext never to end with a 00 byte value. If you know the length in advance, then you could of course use any kind of padding and just toss away the spurious bytes.

Note that padding is only required for CBC and ECB modes of operation (at least for the popular modes of operation), and that for CBC ciphertext stealing could be deployed as well. Currently CTR is becoming more popular (it is also used in most authenticated modes of encryption), and it doesn't require padding.

Note that the Poodle attack is a padding oracle attack. This attack is not possible if the ciphertext is integrity protected. SSL however uses MAC-then-encrypt, which makes the CBC mode of operation vulnerable.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Note that SSL/TLS is not quite the same as PKCS. SSL allowed 1-256 octets padding (not just 1-blocksize) in two notionally separate fields, a padding field of length 0-255 with unspecified and unchecked contents and a length field of 1 octet containing the length 0-255. That unchecked plus MtE gave the oracle. TLS changed to a padding field of length 0-255 with each octet containing the length, plus 1 octet also containing the length. In practice all implementations I've looked at only go up to the next block multiple, but the specs allow any block multiple up to 255+1=256. $\endgroup$
    – dave_thompson_085
    Commented Feb 26, 2015 at 3:50
  • $\begingroup$ @dave_thompson_085 Amended answer. SSL is a strange protocol, too many choices that are not best practice. Fortunately the spec seems to be heading in the right direction. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 26, 2015 at 20:05
5
$\begingroup$

Yes, we always have to pad the message. The reason is simple: How do we know if the message has a padding or not if we don't always pad?

Let's say we pad with adding only $0$ bits. We got the (after padding) message $0101\,1100\,0000\,0000$ and a block size of 2 bytes (16 bits). Well, what was the original message? Was it $0101\,11$? Or was it $0101\,1100$? We don't know.

We can of course pad with one $1$ bit and then as much $0$ bits as needed. This works every time if the message size is not a multiple of the block size, but not anymore of it is exactly a multiple of the block size. We would not know if the last $1$ and $0$s are padding or part of the mssage. Because of this we need to pad even if the message is already in "perfect size".

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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