The Secure Shell (SSH) Transport Layer Encryption Modes
Extracted elements (21)
Although counter mode does not require padding to a multiple of the block length, this document requires such padding to (1) avoid altering the packet description in RFC 4253 and (2) avoid leaking precise information about payload length.
An alternative to the 2**32-packet rekeying recommendation would be to extend the SSH sequence number beyond 32 bits, but this document avoids that approach to preserve interoperability with older SSH implementations.
SDCTR mode is preferred over other provably secure alternatives (described in BKN1/BKN2) because it is the most efficient in terms of both network consumption and number of cryptographic operations per packet.
When SDCTR mode is used, padding in SSH packets need not be random (though it can be), eliminating the need to generate cryptographically secure pseudorandom bytes for each packet—a useful efficiency gain.
The thirteen new SDCTR-mode encryption methods defined in this document are additions to (not replacements for) the encryption methods in RFC 4253 Section 6.3; both sets coexist in the SSH encryption algorithm name registry.
If the block cipher's block length L is less than 128 bits (e.g., 3DES, Blowfish, CAST-128, IDEA), SSH implementations should follow the original RFC 4253 recommendation: rekey at least once for every gigabyte of transmitted data.
SSH implementations SHOULD also attempt to rekey before receiving more than 2**32 packets since the last rekey operation; the preferred approach is to rekey after receiving more than 2**31 packets.
SSH implementations SHOULD rekey at least once every 2**32 outgoing packets. After a key exchange, an SSH implementation SHOULD NOT send more than 2**32 packets before rekeying again.
The encryption methods in each direction of an SSH connection MUST run independently of each other, and the packet length, padding length, payload, and padding fields MUST be encrypted with the chosen method.
The total length of the concatenation of the packet length, padding length, payload, and padding MUST be a multiple of the cipher's block size when the cipher's block size is greater than or equal to 8 bytes.
3des-ctr (RECOMMENDED): Three-key triple-DES (encrypt-decrypt-encrypt) in SDCTR mode; 24 bytes of key data (168 bits used), 8-byte block size. The first 8 bytes are used for the first encryption, next 8 for decryption, last 8 for final encryption.
aes128-ctr (RECOMMENDED): AES in SDCTR mode with 128-bit key and 16-byte block size. aes192-ctr (RECOMMENDED): AES with 192-bit key. aes256-ctr (RECOMMENDED): AES with 256-bit key.
blowfish-ctr (OPTIONAL): Blowfish in SDCTR mode with 256-bit keys and 8-byte block size. Note this differs from blowfish-cbc in RFC 4253, which uses 128-bit keys.
Stateful-decryption counter (SDCTR) mode maintains an internal L-bit counter X initialized to the initial IV interpreted as an L-bit unsigned integer in network-byte-order. The counter wraps from (2**L)-1 to 0.
twofish128-ctr, twofish192-ctr, twofish256-ctr (OPTIONAL): Twofish in SDCTR mode with 128-, 192-, or 256-bit keys respectively; 16-byte block size. serpent128-ctr, serpent192-ctr, serpent256-ctr (OPTIONAL): Serpent in SDCTR mode; 16-byte block size. idea-ctr (OPTIONAL): IDEA in SDCTR mode, 8-byte block. cast128-ctr (OPTIONAL): CAST-128 with 128-bit key, 8-byte block.
Thirteen new encryption algorithm names (aes128-ctr, aes192-ctr, aes256-ctr, 3des-ctr, blowfish-ctr, twofish128-ctr, twofish192-ctr, twofish256-ctr, serpent128-ctr, serpent192-ctr, serpent256-ctr, idea-ctr, cast128-ctr) have been added to the Secure Shell Encryption Algorithm Name registry established by RFC 4250 Section 4.11.1.
Even if the symmetric portion of SSH is implemented exactly as described, applications may still be vulnerable to non-protocol-based attacks (e.g., storing cryptographic keys in cleartext). Proofs of security cover only the symmetric cryptographic portion, not the full application.
If more than 2**32 packets are encrypted and MACed between rekeyings, the SSH Transport Protocol may become vulnerable to replay and re-ordering attacks, and the underlying MAC may begin to leak information about payload data through collisions in the 32-bit sequence number.
Rekeying before encrypting more than 2**(L/4) blocks minimizes the risk of birthday attacks against the block cipher. Using SDCTR mode to encrypt more than 2**L blocks with the same key causes keystream reuse, which can lead to serious privacy attacks.
The original CBC-based encryption methods in RFC 4253 are vulnerable to chosen-plaintext privacy attacks. The new SDCTR mode methods described in this document are provably secure replacements, provided rekeying recommendations are followed and the underlying MAC is secure.
In SDCTR mode, to encrypt packet P=P1||P2||...||Pn, the encryptor encrypts counter value <X> with the block cipher to obtain block B1, then XORs B1 with P1 to produce ciphertext block C1, incrementing X for each subsequent block. The counter X is not included in the ciphertext.