Network Working Group M. Bellare
Request for Comments: 4344 T. Kohno
Category: Standards Track UC San Diego
C. Namprempre
Thammasat University
January 2006
Network Working Group M. Bellare
Request for Comments: 4344 T. Kohno
Category: Standards Track UC San Diego
C. Namprempre
Thammasat University
January 2006
The Secure Shell (SSH) Transport Layer Encryption Modes
安全Shell（SSH）传输层加密模式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.
研究人员发现，当前SSH传输协议的经过身份验证的加密部分容易受到多种攻击。
This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey.
本文档描述了用于Secure Shell（SSH）传输协议的新对称加密方法，并给出了SSH实现重新加密频率的具体建议。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Rekeying ........................................................2
3.1. First Rekeying Recommendation ..............................3
3.2. Second Rekeying Recommendation .............................3
4. Encryption Modes ................................................3
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
6.1. Rekeying Considerations ....................................7
6.2. Encryption Method Considerations ...........................8
Normative References ...............................................9
Informative References ............................................10
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Rekeying ........................................................2
3.1. First Rekeying Recommendation ..............................3
3.2. Second Rekeying Recommendation .............................3
4. Encryption Modes ................................................3
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
6.1. Rekeying Considerations ....................................7
6.2. Encryption Method Considerations ...........................8
Normative References ...............................................9
Informative References ............................................10
The symmetric portion of the SSH Transport Protocol was designed to provide both privacy and integrity of encapsulated data. Researchers ([DAI,BKN1,BKN2]) have, however, identified several security problems with the symmetric portion of the SSH Transport Protocol, as described in [RFC4253]. For example, the encryption mode specified in [RFC4253] is vulnerable to a chosen-plaintext privacy attack. Additionally, if not rekeyed frequently enough, the SSH Transport Protocol may leak information about payload data. This latter property is true regardless of what encryption mode is used.
SSH传输协议的对称部分旨在提供封装数据的隐私性和完整性。然而，研究人员（[DAI，BKN1，BKN2]）发现了SSH传输协议对称部分的几个安全问题，如[RFC4253]所述。例如，[RFC4253]中指定的加密模式容易受到选定的明文隐私攻击。此外，如果没有足够频繁地重新设置密钥，SSH传输协议可能会泄漏有关有效负载数据的信息。无论使用何种加密模式，后一个属性都为true。
In [BKN1,BKN2], Bellare, Kohno, and Namprempre show how to modify the symmetric portion of the SSH Transport Protocol so that it provably preserves privacy and integrity against chosen-plaintext, chosen-ciphertext, and reaction attacks. This document instantiates the recommendations described in [BKN1,BKN2].
在[BKN1、BKN2]中，Bellare、Kohno和Namprempre展示了如何修改SSH传输协议的对称部分，以便它可以针对选择的明文、选择的密文和反应攻击保护隐私和完整性。本文件例举了[BKN1，BKN2]中所述的建议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The used data types and terminology are specified in the architecture document [RFC4251].
所使用的数据类型和术语在架构（architecture）文档[RFC4251]中有详细说明。
The SSH Transport Protocol is specified in the transport document [RFC4253].
SSH传输协议在传输文档[RFC4253]中指定。
Section 9 of [RFC4253] suggests that SSH implementations rekey after every gigabyte of transmitted data. [RFC4253] does not, however, discuss all the problems that could arise if an SSH implementation does not rekey frequently enough. This section serves to strengthen the suggestion in [RFC4253] by giving firm upper bounds on the tolerable number of encryptions between rekeying operations. In Section 6, we discuss the motivation for these rekeying recommendations in more detail.
[RFC4253]的第9节建议SSH实现在每传输一个千兆字节的数据后重新设置密钥。但是，[RFC4253]没有讨论如果SSH实现没有足够频繁地重新设置密钥可能出现的所有问题。本节通过给出密钥更新操作之间可容忍的加密次数的确定上界，加强了[RFC4253]中的建议。在第6节中，我们将更详细地讨论这些重新键入建议的动机。
This section makes two recommendations. Informally, the first recommendation is intended to protect against possible information leakage through the MAC tag, and the second recommendation is intended to protect against possible information leakage through the block cipher. Note that, depending on the block length of the
本节提出两项建议。非正式地，第一个建议旨在防止可能通过MAC标签的信息泄漏，第二个建议旨在防止可能通过分组密码的信息泄漏。请注意，这取决于
underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or vice versa.
根据分组密码和加密数据包的长度，第一个建议可以取代第二个建议，反之亦然。
Because of possible information leakage through the MAC tag, SSH implementations SHOULD rekey at least once every 2**32 outgoing packets. More explicitly, after a key exchange, an SSH implementation SHOULD NOT send more than 2**32 packets before rekeying again.
由于可能通过MAC标记泄漏信息，SSH实现应至少每2**32个传出数据包重新设置一次密钥。更明确地说，在密钥交换之后，SSH实现在再次重新密钥之前不应发送超过2**32个数据包。
SSH implementations SHOULD also attempt to rekey before receiving more than 2**32 packets since the last rekey operation. The preferred way to do this is to rekey after receiving more than 2**31 packets since the last rekey operation.
SSH实现还应在自上次重新设置密钥操作以来收到超过2**32个数据包之前尝试重新设置密钥。执行此操作的首选方法是在自上次重新设置密钥操作以来接收到超过2**31个数据包后重新设置密钥。
Because of a birthday property of block ciphers and some modes of operation, implementations must be careful not to encrypt too many blocks with the same encryption key.
由于分组密码的生日属性和某些操作模式，实现必须小心，不要使用相同的加密密钥加密太多的块。
Let L be the block length (in bits) of an SSH encryption method's block cipher (e.g., 128 for AES). If L is at least 128, then, after rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) blocks before rekeying again. If L is at least 128, then SSH implementations should also attempt to force a rekey before receiving more than 2**(L/4) blocks. If L is less than 128 (which is the case for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, although it may be too expensive to rekey every 2**(L/4) blocks, it is still advisable for SSH implementations to follow the original recommendation in [RFC4253]: rekey at least once for every gigabyte of transmitted data.
设L为SSH加密方法的分组密码的块长度（以位为单位）（例如，AES为128）。如果SSH在执行之前不应加密，那么在执行之后至少不应加密128个块（RE4，REL）。如果L至少为128，则SSH实现还应在接收到超过2**（L/4）个块之前尝试强制重新密钥。如果L小于128（对于3DES、Blowfish、CAST-128和IDEA等较旧的密码就是这种情况），那么，尽管每2**（L/4）个块重新设置密钥的代价可能太高，但SSH实现仍然建议遵循[RFC4253]中的原始建议：对每GB传输的数据至少重新设置一次密钥。
Note that if L is less than or equal to 128, then the recommendation in this subsection supersedes the recommendation in Section 3.1. If an SSH implementation uses a block cipher with a larger block size (e.g., Rijndael with 256-bit blocks), then the recommendations in Section 3.1 may supersede the recommendations in this subsection (depending on the lengths of the packets).
请注意，如果L小于或等于128，则本小节中的建议将取代第3.1节中的建议。如果SSH实现使用块大小更大的块密码（例如，具有256位块的Rijndael），则第3.1节中的建议可能会取代本小节中的建议（取决于数据包的长度）。
This document describes new encryption methods for use with the SSH Transport Protocol. These encryption methods are in addition to the encryption methods described in Section 6.3 of [RFC4253].
本文档描述了用于SSH传输协议的新加密方法。这些加密方法是[RFC4253]第6.3节所述加密方法的补充。
Recall from [RFC4253] that the encryption methods in each direction of an SSH connection MUST run independently of each other and that, when encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the chosen method. Further recall that 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 (which is the case for all of the following methods).
回想一下[RFC4253]，SSH连接的每个方向上的加密方法必须彼此独立运行，并且当加密生效时，每个数据包的数据包长度、填充长度、有效负载和填充字段必须使用所选方法进行加密。当padding或call的总长度大于块密码大小的8时，该值必须大于块密码大小的8。
This document describes the following new methods:
本文档介绍了以下新方法：
aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode twofish128-ctr OPTIONAL Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr OPTIONAL Serpent in SDCTR mode, with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode, with 128-bit key
aes128 ctr推荐AES（Rijndael）在SDCTR模式下，使用128位键aes192 ctr推荐AES在192位键aes256 ctr推荐AES在SDCTR模式下使用256位键3des ctr推荐三个键3DE河豚ctr在SDCTR模式下可选河豚Twofish 128 ctr在SDCTR模式下可选Twofish，128位密钥twofish192 ctr可选Twofish 192位密钥twofish256 ctr可选Twofish 256位密钥Serpent 128 ctr可选Serpent在SDCTR模式下，128位密钥蛇192 ctr可选蛇192位密钥蛇256 ctr可选蛇256位密钥蛇idea ctr可选idea SDCTR模式cast128 ctr可选CAST-128 SDCTR模式，128位密钥
The label <cipher>-ctr indicates that the block cipher <cipher> is to be used in "stateful-decryption counter" (SDCTR) mode. Let L be the block length of <cipher> in bits. In stateful-decryption counter mode, both the sender and the receiver maintain an internal L-bit counter X. The initial value of X should be the initial IV (as computed in Section 7.2 of [RFC4253]) interpreted as an L-bit unsigned integer in network-byte-order. If X=(2**L)-1, then "increment X" has the traditional semantics of "set X to 0." We use the notation <X> to mean "convert X to an L-bit string in network-byte-order." Naturally, implementations may differ in how the internal value X is stored. For example, implementations may store X as multiple unsigned 32-bit counters.
标签<cipher>-ctr表示分组密码<cipher>将在“有状态解密计数器”（SDCTR）模式下使用。设L为<cipher>的块长度，单位为位。在有状态解密计数器模式下，发送方和接收方均保持一个内部L位计数器X。X的初始值应为初始IV（如[RFC4253]第7.2节中计算的），并按网络字节顺序解释为L位无符号整数。如果X=（2**L）-1，则“增量X”具有“将X设置为0”的传统语义。我们使用符号<X>来表示“将X转换为网络字节顺序的L位字符串”。当然，内部值X的存储方式可能会有所不同。例如，实现可以将X存储为多个无符号32位计数器。
To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each blocks of length L), the encryptor first encrypts <X> with <cipher> to obtain a block B1. The block B1 is then XORed with P1 to generate the ciphertext block C1. The counter X is then incremented, and the process is repeated for each subsequent block in order to generate
为了加密分组P=P1 | | P2 | | |…| | | Pn（其中P1，P2，…，Pn是长度为L的每个块），加密器首先用<cipher>加密<X>以获得块B1。然后将块B1与P1异或以生成密文块C1。然后计数器X递增，并对每个后续块重复该过程以生成
the entire ciphertext C=C1||C2||...||Cn corresponding to the packet P. Note that the counter X is not included in the ciphertext. Also note that the keystream can be pre-computed and that encryption is parallelizable.
与数据包P相对应的整个密文C=C1 | | C2 | |…| | Cn。请注意，密文中不包括计数器X。还要注意，密钥流可以预先计算，并且加密是可并行的。
To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also maintains its own copy of X) first encrypts its copy of <X> with <cipher> to generate a block B1 and then XORs B1 to C1 to get P1. The decryptor then increments its copy of the counter X and repeats the above process for each block to obtain the plaintext packet P=P1||P2||...||Pn. As before, the keystream can be pre-computed, and decryption is parallelizable.
要解密密文C=C1 | | C2 | | | | | | | | Cn，解密程序（同时维护其自己的X副本）首先使用<cipher>加密其<X>副本以生成块B1，然后对B1进行异或运算以获得P1。然后，解密器增加其计数器X的副本，并对每个块重复上述过程，以获得明文分组P＝P1 | | | P2 | | | Pn。和以前一样，可以预先计算密钥流，并且解密是可并行的。
The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes.
“aes128 ctr”方法使用AES（高级加密标准，前身为Rijndael）和128位密钥[AES]。块大小为16字节。
At this time, it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged.
此时，未来的规范可能会促进要求aes128 ctr；强烈鼓励实施该算法。
The "aes192-ctr" method uses AES with 192-bit keys.
“aes192 ctr”方法使用带有192位密钥的AES。
The "aes256-ctr" method uses AES with 256-bit keys.
“aes256 ctr”方法使用带256位密钥的AES。
The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt-encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). The block size is 8 bytes. This algorithm is defined in [DES].
“3des ctr”方法使用三个密钥三重DES（encrypt-decrypt-encrypt），其中密钥的前8个字节用于第一次加密，后8个字节用于解密，后8个字节用于最终加密。这需要24字节的密钥数据（其中实际使用了168位）。块大小为8字节。该算法在[DES]中定义。
The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER]. The block size is 8 bytes. (Note that "blowfish-cbc" from [RFC4253] uses 128-bit keys.)
“blowfish ctr”方法使用具有256位键的blowfish[SCHNEIER]。块大小为8字节。（请注意，[RFC4253]中的“河豚cbc”使用128位密钥。）
The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The block size is 16 bytes.
“twofish128 ctr”方法使用具有128位密钥的Twofish[Twofish]。块大小为16字节。
The "twofish192-ctr" method uses Twofish with 192-bit keys.
“twofish192 ctr”方法使用具有192位密钥的Twofish。
The "twofish256-ctr" method uses Twofish with 256-bit keys.
“twofish256 ctr”方法使用带有256位键的Twofish。
The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] with 128-bit keys. The block size is 16 bytes.
“Serpent 128 ctr”方法使用具有128位密钥的Serpent分组密码[Serpent]。块大小为16字节。
The "serpent192-ctr" method uses Serpent with 192-bit keys.
“serpent192 ctr”方法使用带有192位密钥的Serpent。
The "serpent256-ctr" method uses Serpent with 256-bit keys.
“serpent256 ctr”方法使用带有256位键的Serpent。
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block size is 8 bytes.
“idea ctr”方法使用idea密码[SCHNEIER]。块大小为8字节。
The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys [RFC2144]. The block size is 8 bytes.
“cast128 ctr”方法使用具有128位密钥的CAST-128密码[RFC2144]。块大小为8字节。
The thirteen encryption algorithm names defined in Section 4 have been added to the Secure Shell Encryption Algorithm Name registry established by Section 4.11.1 of [RFC4250].
第4节中定义的13个加密算法名称已添加到[RFC4250]第4.11.1节建立的安全外壳加密算法名称注册表中。
This document describes additional encryption methods and recommendations for the SSH Transport Protocol [RFC4253]. [BKN1,BKN2] prove that if an SSH application incorporates the methods and recommendations described in this document, then the symmetric cryptographic portion of that application will resist a large class of privacy and integrity attacks.
本文档描述了SSH传输协议[RFC4253]的其他加密方法和建议。[BKN1，BKN2]证明，如果SSH应用程序包含本文档中描述的方法和建议，那么该应用程序的对称加密部分将抵御一大类隐私和完整性攻击。
This section is designed to help implementors understand the security-related motivations for, as well as possible consequences of deviating from, the methods and recommendations described in this document. Additional motivation and discussion, as well as proofs of security, appear in the research papers [BKN1,BKN2].
本节旨在帮助实施者了解偏离本文档中描述的方法和建议的安全相关动机以及可能的后果。研究论文[BKN1，BKN2]中出现了其他动机和讨论，以及安全性证明。
Please note that the notion of "prove" in the context of [BKN1,BKN2] is that of practice-oriented reductionist security: if an attacker is able to break the symmetric portion of the SSH Transport Protocol using a certain type of attack (e.g., a chosen-ciphertext attack), then the attacker will also be able to break one of the transport protocol's underlying components (e.g., the underlying block cipher or MAC). If we make the reasonable assumption that the underlying components (such as AES and HMAC-SHA1) are secure, then the attacker against the symmetric portion of the SSH protocol cannot be very successful (since otherwise there would be a contradiction). Please see [BKN1,BKN2] for details. In particular, attacks are not impossible, just extremely improbable (unless the building blocks, like AES, are insecure).
请注意，在[BKN1，BKN2]的上下文中，“证明”的概念是面向实践的简化论安全：如果攻击者能够使用某种类型的攻击（例如，选择的密文攻击）破坏SSH传输协议的对称部分，然后，攻击者还可以破坏传输协议的一个底层组件（例如，底层分组密码或MAC）。如果我们合理地假设底层组件（如AES和HMAC-SHA1）是安全的，那么针对SSH协议对称部分的攻击者就不可能非常成功（因为否则就会产生矛盾）。详情请参见[BKN1，BKN2]。特别是，攻击并非不可能，只是极不可能（除非构建块（如AES）不安全）。
Note also that cryptography often plays only a small (but critical) role in an application's overall security. In the case of the SSH Transport Protocol, even though an application might implement the symmetric portion of the SSH protocol exactly as described in this document, the application may still be vulnerable to non-protocol-
还要注意的是，加密技术在应用程序的整体安全性中通常只起到很小（但很关键）的作用。在SSH传输协议的情况下，即使应用程序可能完全按照本文档中的描述实现SSH协议的对称部分，应用程序仍然可能容易受到非协议攻击-
based attacks (as an egregious example, an application might save cryptographic keys in cleartext to an unprotected file). Consequently, even though the methods described herein come with proofs of security, developers must still execute caution when developing applications that implement these methods.
基于密码的攻击（作为一个惊人的例子，应用程序可能以明文形式将加密密钥保存到未受保护的文件中）。因此，即使本文描述的方法具有安全性证明，开发人员在开发实现这些方法的应用程序时仍必须谨慎。
Section 3 of this document makes two rekeying recommendations: (1) rekey at least once every 2**32 packets, and (2) rekey after a certain number of encrypted blocks (e.g., 2**(L/4) blocks if the block cipher's block length L is at least 128 bits). The motivations for recommendations (1) and (2) are different, and we consider each recommendation in turn. Briefly, (1) is designed to protect against information leakage through the SSH protocol's underlying MAC, and (2) is designed to protect against information leakage through the SSH protocol's underlying encryption scheme. Please note that, depending on the encryption method's block length L and the number of blocks encrypted per packet, recommendation (1) may supersede recommendation (2) or vice versa.
本文件第3节提出了两种密钥更新建议：（1）至少每2**32个数据包更新一次密钥，以及（2）在一定数量的加密块（例如，如果分组密码的块长度L至少为128位，则为2**（L/4）个数据块）之后更新密钥。建议的动机（1）和（2）是不同的，我们依次考虑每一个建议。简单地说，（1）旨在通过SSH协议的底层MAC防止信息泄漏，（2）旨在通过SSH协议的底层加密方案防止信息泄漏。请注意，根据加密方法的块长度L和每个数据包加密的块数，建议（1）可能取代建议（2），反之亦然。
Recommendation (1) states that SSH implementations should rekey at least once every 2**32 packets. If more than 2**32 packets are encrypted and MACed by the SSH Transport Protocol between rekeyings, then the SSH Transport Protocol may become vulnerable to replay and re-ordering attacks. This means that an adversary may be able to convince the receiver to accept the same message more than once or to accept messages out of order. Additionally, the underlying MAC may begin to leak information about the protocol's payload data. In more detail, an adversary looks for a collision between the MACs associated to two packets that were MACed with the same 32-bit sequence number (see Section 4.4 of [RFC4253]). If a collision is found, then the payload data associated with those two ciphertexts is probably identical. Note that this problem occurs regardless of how secure the underlying encryption method is. Also note that although compressing payload data before encrypting and MACing and the use of random padding may reduce the risk of information leakage through the underlying MAC, compression and the use of random padding will not prevent information leakage. Implementors who decide not to rekey at least once every 2**32 packets should understand these issues. These issues are discussed further in [BKN1,BKN2].
建议（1）指出，SSH实现应至少每2**32个数据包重新设置一次密钥。如果SSH传输协议在密钥更新之间对超过2**32个数据包进行加密和篡改，则SSH传输协议可能容易受到重播和重新排序攻击。这意味着对手可以说服接收者多次接受同一消息，或者接受无序的消息。此外，底层MAC可能开始泄漏关于协议有效负载数据的信息。更详细地说，敌方寻找与两个数据包相关的MAC之间的冲突，这两个数据包使用相同的32位序列号（参见[RFC4253]第4.4节）。如果发现冲突，则与这两个密文关联的有效负载数据可能相同。请注意，无论底层加密方法有多安全，都会出现此问题。还请注意，尽管在加密和MAC之前压缩有效负载数据以及使用随机填充可以降低通过底层MAC的信息泄漏风险，但压缩和使用随机填充将不会防止信息泄漏。决定不至少每2**32个数据包重新键入一次的实现者应该了解这些问题。这些问题将在[BKN1，BKN2]中进一步讨论。
One alternative to recommendation (1) would be to make the SSH Transport Protocol's sequence number more than 32 bits long. This document does not suggest increasing the length of the sequence number because doing so could hinder interoperability with older versions of the SSH protocol. Another alternative to recommendation (1) would be to switch from basic HMAC to a another MAC, such as a
建议（1）的一个替代方案是使SSH传输协议的序列号长度超过32位。本文档不建议增加序列号的长度，因为这样做可能会妨碍与较旧版本的SSH协议的互操作性。建议（1）的另一个替代方案是从基本HMAC切换到另一个MAC，例如
MAC that has its own internal counter. Because of the 32-bit counter already present in the protocol, such a counter would only need to be incremented once every 2**32 packets.
有自己内部计数器的MAC。由于协议中已经存在32位计数器，这样的计数器只需每2**32个数据包增加一次。
Recommendation (2) states that SSH implementations should rekey before encrypting more than 2**(L/4) blocks with the same key (assuming L is at least 128). This recommendation is designed to minimize the risk of birthday attacks against the encryption method's underlying block cipher. For example, there is a theoretical privacy attack against stateful-decryption counter mode if an adversary is allowed to encrypt approximately 2**(L/2) messages with the same key. It is because of these birthday attacks that implementors are highly encouraged to use secure block ciphers with large block lengths. Additionally, recommendation (2) is designed to protect an encryptor from encrypting more than 2**L blocks with the same key. The motivation here is that, if an encryptor were to use SDCTR mode to encrypt more than 2**L blocks with the same key, then the encryptor would reuse keystream, and the reuse of keystream can lead to serious privacy attacks [SCHNEIER].
建议（2）指出，SSH实现应在使用相同密钥加密2个以上**（L/4）块之前重新设置密钥（假设L至少为128）。此建议旨在最大限度地降低针对加密方法的底层分组密码的生日攻击风险。例如，如果允许对手使用相同密钥加密大约2**（L/2）条消息，则理论上存在针对有状态解密计数器模式的隐私攻击。正是由于这些生日攻击，强烈鼓励实现者使用具有大数据块长度的安全分组密码。此外，建议（2）旨在保护加密机不使用相同密钥加密超过2**L个块。这里的动机是，如果加密机使用SDCTR模式用同一密钥加密2**L以上的块，则加密机将重用密钥流，而密钥流的重用可能导致严重的隐私攻击[SCHNEIER]。
Researchers have shown that the original CBC-based encryption methods in [RFC4253] are vulnerable to chosen-plaintext privacy attacks [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption methods described in Section 4 of this document were designed to be secure replacements to the original encryption methods described in [RFC4253].
研究人员已经表明，[RFC4253]中最初基于CBC的加密方法容易受到选择的明文隐私攻击[DAI，BKN1，BKN2]。本文件第4节中描述的新的有状态解密计数器模式加密方法旨在安全地替代[RFC4253]中描述的原始加密方法。
Many people shy away from counter mode-based encryption schemes because, when used incorrectly (such as when the keystream is allowed to repeat), counter mode can be very insecure. Fortunately, the common concerns with counter mode do not apply to SSH because of the rekeying recommendations and because of the additional protection provided by the transport protocol's MAC. This discussion is formalized with proofs of security in [BKN1,BKN2].
许多人回避基于计数器模式的加密方案，因为如果使用不当（例如，当允许密钥流重复时），计数器模式可能非常不安全。幸运的是，由于密钥更新建议和传输协议的MAC提供的额外保护，计数器模式的常见问题不适用于SSH。此讨论在[BKN1，BKN2]中通过安全性证明形式化。
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.
作为补充说明，当使用一种有状态解密计数器模式加密方法（第4节）时，SSH数据包（RFC4253的第4节）中包含的填充不需要（但仍然可以）随机。这消除了为每个数据包生成加密安全伪随机字节的需要。
One property of counter mode encryption is that it does not require that messages be padded to a multiple of the block cipher's block length. Although not padding messages can reduce the protocol's network consumption, this document requires that padding be a multiple of the block cipher's block length in order to (1) not alter
计数器模式加密的一个特性是，它不需要将消息填充到分组密码块长度的倍数。虽然不填充消息可以减少协议的网络消耗，但本文档要求填充是分组密码块长度的倍数，以便（1）不改变
the packet description in [RFC4253] and (2) not leak precise information about the length of the packet's payload data. (Although there may be some network savings from padding to only 8-bytes even if the block cipher uses 16-byte blocks, because of (1) we do not make that recommendation here.)
[RFC4253]和（2）中的数据包描述没有泄漏关于数据包有效负载数据长度的精确信息。（尽管即使分组密码使用16字节的块，从填充到仅8字节可能会节省一些网络开销，因为（1）我们在这里不建议这样做。）
In addition to stateful-decryption counter mode, [BKN1,BKN2] describe other provably secure encryption methods for use with the SSH Transport Protocol. The stateful-decryption counter mode methods in Section 4 are, however, the preferred alternatives to the insecure methods in [RFC4253] because stateful-decryption counter mode is the most efficient (in terms of both network consumption and the number of required cryptographic operations per packet).
除了有状态解密计数器模式外，[BKN1，BKN2]还描述了用于SSH传输协议的其他可证明安全的加密方法。然而，第4节中的有状态解密计数器模式方法是[RFC4253]中不安全方法的首选替代方法，因为有状态解密计数器模式是最有效的（就网络消耗和每个数据包所需的加密操作数量而言）。
Normative References
规范性引用文件
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，联邦信息处理标准出版物197，2001年11月。
[DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999.
[DES]国家标准与技术研究所，“数据加密标准（DES）”，联邦信息处理标准出版物46-3，1999年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]Adams，C.，“CAST-128加密算法”，RFC2144，1997年5月。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]Lehtinen，S.和C.Lonvick，Ed.，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996.
[SCHNEIER]SCHNEIER，B.，“应用密码学第二版：C语言中的协议、算法和源代码”，Wiley，1996年。
[SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998.
[SERPENT]Anderson，R.，Biham，E.，和Knudsen，L.，“蛇：高级加密标准提案”，NIST AES提案，1998年。
[TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999.
[TWOFISH]Schneier，B.等人，“TWOFISH加密算法：128位分组密码，第1版”，Wiley，1999年。
Informative References
资料性引用
[BKN1] Bellare, M., Kohno, T., and Namprempre, C., "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol", Ninth ACM Conference on Computer and Communications Security, 2002.
[BKN1]Bellare，M.，Kohno，T.，和Namprempre，C.，“SSH中的认证加密：可证明地修复SSH二进制数据包协议”，第九届ACM计算机和通信安全会议，2002年。
[BKN2] Bellare, M., Kohno, T., and Namprempre, C., "Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm", ACM Transactions on Information and System Security, 7(2), May 2004.
[BKN2]Bellare，M.，Kohno，T.，和Namprempre，C.，“破坏并可证明地修复SSH认证加密方案：编码-然后加密和MAC范式的案例研究”，ACM信息和系统安全事务，7（2），2004年5月。
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the ietf-ssh@netbsd.org email list, 2002.
[DAI]DAI，W.，“对SSH2协议的攻击”，给ietf的电子邮件-ssh@netbsd.org电子邮件列表，2002年。
Authors' Addresses
作者地址
Mihir Bellare Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404
米歇尔贝拉雷加州大学圣地亚哥分校计算机科学与工程系9500吉尔曼驱动，MC 0404拉霍拉，CA 92093-0404
Phone: +1 858-534-8833
EMail: mihir@cs.ucsd.edu
Phone: +1 858-534-8833
EMail: mihir@cs.ucsd.edu
Tadayoshi Kohno Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404
加州大学圣地亚哥分校计算机科学与工程系，9500吉尔曼驱动，MC 0404拉霍拉，CA 92093-0404
Phone: +1 858-534-8833
EMail: tkohno@cs.ucsd.edu
Phone: +1 858-534-8833
EMail: tkohno@cs.ucsd.edu
Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121
Chanathip Namprempre Thammasat大学工程学院电气工程系泰国Klong Luang Pathumthani Rangsit校区12121
EMail: meaw@alum.mit.edu
EMail: meaw@alum.mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。