Is an attacker able to intercept tls communication and get cleartext size information from the encrypted size of intercepted payloads? Or is there some kind of padding which would prevent messages such as yes (3 letters) and no (2 letters) from producing different size (larger for yes)?


It depends on many parameters, such as the encryption algorithm used, the specific mode being used, and the exact difference of data.

For example AES uses block sizes of 16 bytes, and will always pad up to 16 bytes. Any message that is not a multiple of 16 bytes will therefore be padded up to 16 bytes. In your example with yes and no, this means that both will end up being 16 bytes long.

It furthermore depends on the length of those messages. If one message is 2 bytes long, and the other is two terabytes long, then no amount of "automatic" (meaning, as being part of the algorithm) will save you. You can of course manually pad a 2 byte message up to 2 terabytes, but it will be very wasteful.

So if your confidentiality depends on the fact that two ciphertexts are indistinguishable, then you need to manually pad the plaintexts.

  • In 1.2 for older (nonAEAD) ciphersuites it can also depend (though not in this case) on whether both peers support rfc7366 encrypt-then-mac. Theoretically it could also depend on support of compression, but that is almost never since CRIME in 2012. In 1.3 length hiding no longer depends on mode because all ciphers are effectively stream with no encryption padding, but there is a new (and more clearly explained) option for plaintext-level padding which either or both peer(s) may use. – dave_thompson_085 Jan 24 at 3:05

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.