1
$\begingroup$

In am learning the SSH RFC

An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the given algorithm.

So the structure of the packet would be like that. How does the SSH server or client know the real length of the encrypted data?

                                  payload
                 [byte[packet_length - padding_length - 1]]
                                     ^
                                     |
       packet_length                 |             mac (Message Authentication Code - MAC)
          [uint32]                   |                        [byte[mac_length]]
             ^                       |                                ^
             |                       |                                |
             |                       |                                |
+-------+--------------------------------------------------------------------+
|       |    |                       |   ssh                          |      |
|       | +----------------------------------------------------------------+ |
|       | |-----------------------------------------------------|     |    | |
|       | || |  |   |                |               |         ||     |    | |
|  tcp  | || |  |   |                |               |         ||     |    | |
|       | || +  | + |            +   +               |    +    ||     +    | |
|       | ||    | | |            |                   |    |    ||          | |
|       | |-----------------------------------------------------|          | |
|       | |----------------------------------------------------------------+ |
+-------+--------------------------------------------------------------------+
                  |              |                        |
                  |              |                        |
                  |              |                        |
                  v              |                        v
               [byte]            |              [byte[padding_length]]
            padding_length       |                  random padding
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                                 v
                           encrypted_data
Improve this question
$\endgroup$
2
  • $\begingroup$ This question has nothing to do with Cryptography. This is basic TCP/IP problem. $\endgroup$
    – kelalaka
    Apr 28, 2019 at 14:07
  • $\begingroup$ Possibly but this is a question about a cryptographic protocol, and hence I'm allowing this question. TCP is a streaming protocol, so I don't see how that transmits the message size other than closing the connection, and I'd be surprised if that's used. $\endgroup$
    – Maarten Bodewes ♦
    Apr 28, 2019 at 15:50

2 Answers 2

Reset to default
3
$\begingroup$

Quoting the SSH protocol:

"Note that the 'packet_length' field is also encrypted, and processing it requires special care when sending or receiving packets."

Generally ciphers process bytes from left to right. This means that the packet length can be available before the encryption is ended (or before all the information is received, for that matter).

This is a horrible protocol decision because it means you have to interleave between the packet decoding and decryption layer, and you will get the message length before it is authenticated. Still, it is practically doable.

There is probably one advantage: you can add more padding to avoid some side channel attacks that use the length of the send packages. However, this advantage is hard to use, because you'd now also have to mix the application and encryption code.

Note that the other sizes - such as MAC length - are determined by the protocol and protocol configuration during the handshake.

Improve this answer
$\endgroup$
1
  • $\begingroup$ However I read almost whole RFC and there is no specific packet length configuration but an agreement about the max length and min length.As far as I knew TCP is a streaming protocol, so how does the SSH process to detect the packet boundary once the receiver process didn't receive the data from system buffer and 2 time's data stick together. $\endgroup$
    – Anon
    Apr 29, 2019 at 2:19
-1
$\begingroup$

I think your problem solution is in TCP header. With reference to TCP header, there is a field called 'HLen' which means header-length. By stripping off this header the whole remaining bits are the SSH package (i mean header and data). SSH can decrypt this whole package of bits and then starts reading the decrypted packet according to SSH semantics. SSH semantics says: first 4 bytes are the Packet-length. The 5th byte is the padding length ... So on

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ In the end TCP turns a data stream in to a series of messages / segments. However, that kind of functionality is commonly hidden to the user (it is a layered architecture after all, even though TCP/IP is not strictly OSI). If you're correct then you'd need access to information present on a lower level. $\endgroup$
    – Maarten Bodewes ♦
    Apr 28, 2019 at 14:42
  • $\begingroup$ No layer in TCP/IP or OSI models have access to the information of another layer. After all, segmentation/reassembly is a L4 problem. In this case, SSH must control buffer size before sending data to the TCP socket. buffer must be small enough to guarantee MAC correctness and cipher padding correctness. Also, note that most terminal systems work in character mode, which means send one byte as the user type it in. $\endgroup$
    – m.nasim
    Apr 28, 2019 at 14:51

Your Answer

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

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