4

From RFC 4253:

 Each packet is in the following format: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (Message Authentication Code - MAC); m = mac_length [...] random padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || random padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes.

Why does SSH require (or recommend with SHOULD) random padding, as opposed to non-random padding?

And why does RFC 4344 say that it is not necessary when using CTR mode?

 As an additional note, when one of the stateful-decryption counter mode encryption methods (Section 4) is used, then the padding included in an SSH packet (Section 4 of [RFC4253]) need not be (but can still be) random. This eliminates the need to generate cryptographically secure pseudorandom bytes for each packet.
Improve this question
1
  • 1
    SSH2 (standardly) MACs plaintext not ciphertext, and unprotected CBC allows moving block pairs (CTR does not), which I think enables padding-oracle attacks if the receiver imposes any constraint -- which means random must be permitted, but I don't see how that makes it preferred. Commented May 6, 2017 at 6:19

3 Answers 3

Reset to default
3

Padding is used to fill up plaintext to the blocklength of the cipher. This is not needed for counter mode, since it has no blocks and can encrypt any length.

There are different styles of padding, some are optimized to recognize changes or the actual length of the data. In case of the SSH sheme where a extra field specified the length no special pattern is needed, so random content provides the least information for attackers.

In SSH you can add padding longer than to the end of the block (I.e. To the next block or even more). This helps to make it harder for attackers to guess the actual plaintext length.

Especially for command/response sessions a lot can be learned if the cipher leaks the length. This is called traffic analysis and random padding length somewhat helps against it.

Improve this answer
2
  • I know what the padding is for, but I'm wondering why it needs to be random. RFC 4344 Section 4 specifies that padding is still used in CTR mode, so why does it need to be random only in CBC? Commented May 7, 2017 at 3:34
  • It is not strictly needed (it’s a should statement anyway) for most modern modes, but as I said adds some best practice belts and suspenders by removing unnecessary predictable content which could help an attacker with analysis or bruteforce. Btw the term random also means the decrypt can’t rely on any specific padding content. And also it makes a modular specification much easier if the spec for the field is the same in all cases. (I think the more interesting question is why it has a mandatory min8mal length of 4) Commented Jan 27, 2024 at 23:21
2

Modern block ciphers are explicitly designed to account for any systemic input bias, which not using random padding could introduce.

The usage of a simple deterministic input function used to be controversial; critics argued that "deliberately exposing a cryptosystem to a known systematic input represents an unnecessary risk." However, today CTR mode is widely accepted and any problems are considered a weakness of the underlying block cipher, which is expected to be secure regardless of systemic bias in its input.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CTR

Improve this answer
2
  • 1
    Interesting... That Wikipedia page attributes the changed attitude to modern block ciphers (presumably like AES), and concludes that CTR mode is OK because the block ciphers are secure, but RFC 4344 seems to attribute the changed attitude to CTR mode itself: "when one of the stateful-decryption counter mode encryption methods (Section 4) is used, then the padding included in an SSH packet (Section 4 of [RFC4253]) need not be (but can still be) random." Commented May 9, 2017 at 15:05
  • 1
    I guess CTR mode doesn't put the plaintext straight into the cipher, but rather XORs the plaintext with the cipher output. I wonder if this eliminates concerns with input bias... Commented May 9, 2017 at 15:07
0

One area random padding can be useful is defending against certain types of timing analysis attacks. See this paper, Timing analysis in low-latency mix networks:attacks and defenses, from the University of Austin.

That being said, simple random padding is a poor defense against certain types of timing analysis attacks. I could still probably tell you are steaming a Netflix show even with random padding. This is an area of concern for ssh that I've yet to see a solid solution for.

How can ssh defend against timing analysis attacks?

Improve this answer
2
  • The random padding in SSH to which I'm referring is random padding that brings the plaintext payload up to a multiple of the cipher block size. I'm wondering why the padding is recommended to be random, as opposed to non-random. If it is encrypted, why does it matter? Padding to combat timing analysis is another issue, I believe. SSH provides SSH_MSG_IGNORE (RFC 4253 Section 11.2) for this purpose. Commented May 8, 2017 at 22:39
  • Ah, not random length padding but random bits in the used padding. Commented May 8, 2017 at 23:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.