3

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.
Community
  • 1
jtpereyda
  • 1,500
  • 2
  • 16
  • 26
  • 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_. – dave_thompson_085 May 06 '17 at 06:19

3 Answers3

2

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.

eckes
  • 962
  • 8
  • 19
  • 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? – jtpereyda May 07 '17 at 03:34
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

Zamicol
  • 220
  • 1
  • 6
  • 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." – jtpereyda May 09 '17 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... – jtpereyda May 09 '17 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?

Zamicol
  • 220
  • 1
  • 6
  • 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. – jtpereyda May 08 '17 at 22:39
  • Ah, not random length padding but random bits in the used padding. – Zamicol May 08 '17 at 23:18