Network Working Group B. Harris
Request for Comments: 4345 January 2006
Category: Standards Track
Network Working Group B. Harris
Request for Comments: 4345 January 2006
Category: Standards Track
Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
安全外壳（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
摘要
This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm.
本文档指定了在SecureShell（SSH）协议中使用Arcfour密码的方法，以缓解密码密钥调度算法的弱点。
Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. It allows for the use of an extensible variety of symmetric cipher algorithms to provide confidentiality for data in transit. One of the algorithms specified in the base protocol is "arcfour", which specifies the use of Arcfour (also known as RC4), a fast stream cipher. As [RFC4253] says, though, "Arcfour (and RC4) has problems with weak keys, and should be used with caution." These problems are described in more detail in [MANTIN01], along with a recommendation to discard the first 1536 bytes of keystream so as to ensure that the cipher's internal state is thoroughly mixed. This document specifies new cipher algorithms for SSH that follow this recommendation.
Secure Shell（SSH）[RFC4251]是一种安全的远程登录协议。它允许使用各种可扩展的对称密码算法为传输中的数据提供机密性。基本协议中指定的算法之一是“arcfour”，它指定使用arcfour（也称为RC4），一种快速流密码。正如[RFC4253]所说，“Arcfour（和RC4）存在弱密钥问题，应谨慎使用。”这些问题在[MANTIN01]中有更详细的描述，并建议丢弃密钥流的前1536字节，以确保密码的内部状态完全混合。本文档指定了遵循此建议的SSH新密码算法。
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]中所述进行解释。
Implementations of Arcfour are typically slightly faster and much smaller than those of any other encryption algorithm currently defined for SSH. This must be balanced, though, against the known security problems with Arcfour described in Section 5. In most cases, where speed and code size are not critical issues, the algorithms specified by [RFC4344] should be used instead.
Arcfour的实现通常比目前为SSH定义的任何其他加密算法都要稍微快一些，而且要小得多。但是，这必须与第5节中描述的Arcfour的已知安全问题相平衡。在大多数情况下，如果速度和代码大小不是关键问题，则应使用[RFC4344]指定的算法。
The "arcfour128" algorithm is the RC4 cipher, as described in [SCHNEIER], using a 128-bit key. The first 1536 bytes of keystream generated by the cipher MUST be discarded, and the first byte of the first encrypted packet MUST be encrypted using the 1537th byte of keystream.
“arcfour128”算法是RC4密码，如[SCHNEIER]所述，使用128位密钥。必须丢弃密码生成的密钥流的前1536字节，并且必须使用密钥流的1537字节对第一个加密数据包的第一个字节进行加密。
The "arcfour256" algorithm is the same, but uses a 256-bit key.
“arcfour256”算法相同，但使用256位密钥。
The security considerations in [RFC4251] apply.
[RFC4251]中的安全注意事项适用。
The discarded bytes of keystream MUST be kept secret and MUST NOT be transmitted over the network. The contents of these bytes could reveal information about the key.
密钥流的丢弃字节必须保密，不得通过网络传输。这些字节的内容可能会显示有关密钥的信息。
There are two classes of attack on Arcfour described in [MIRONOV]. Strong distinguishers distinguish an Arcfour keystream from randomness at the start of the stream and are defended against by the algorithm defined in this document. Weak distinguishers can operate on any part of the keystream, and the best ones, described in [FMcG] and [MANTIN05], can use data from multiple, different keystreams. A consequence of this is that encrypting the same data (for instance, a password) sufficiently many times in separate Arcfour keystreams can be sufficient to leak information about it to an adversary. It is thus RECOMMENDED that Arcfour (either in the form described here or that described in [RFC4251]) not be used for high-volume password-authenticated connections.
[MIRONOV]中描述了对Arcfour的两类攻击。强区分器将Arcfour keystream与流开始时的随机性区分开来，并通过本文中定义的算法进行防御。弱识别器可以在钥匙流的任何部分上工作，最好的识别器，如[FMcG]和[MANTIN05]中所述，可以使用来自多个不同钥匙流的数据。这样做的结果是，在单独的Arcfour密钥流中对相同的数据（例如，密码）进行足够多次的加密，就足以将有关该数据的信息泄漏给对手。因此，建议不要将Arcfour（此处描述的形式或[RFC4251]中描述的形式）用于大容量密码验证连接。
The IANA has assigned the Encryption Algorithm Names "arcfour128" and "arcfour256" in accordance with [RFC4250].
IANA已根据[RFC4250]分配加密算法名称“arcfour128”和“arcfour256”。
[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月。
[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月
[RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, January 2006.
[RFC4344]Bellare，M.，Kohno，T.，和C.Namprempre，“安全外壳（SSH）传输层加密模式”，RFC 4344，2006年1月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996.
[SCHNEIER]SCHNEIER，B.，“应用密码学第二版：C语言中的协议、算法和源代码”，John Wiley and Sons，纽约，纽约，1996年。
[FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the Alleged RC4 Keystream Generator", Fast Software Encryption: 7th International Workshop, FSE 2000, April 2000, <http://www.mindspring.com/~dmcgrew/rc4-03.pdf>.
[FMcG]Fluhrer，S.和D.McGrew，“所谓RC4密钥流生成器的统计分析”，快速软件加密：第七届国际研讨会，FSE 2000，2000年4月<http://www.mindspring.com/~dmcgrew/rc4-03.pdf>。
[MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. Thesis, Weizmann Institute of Science, 2001, <http:// www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip>.
[MANTIN01]Mantin，I.，“流密码RC4的分析”，M.Sc。论文，魏茨曼科学研究所，2001年，<http://www.wist.Weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip>。
[MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances in Cryptology -- CRYPTO 2002: 22nd Annual International Cryptology Conference, August 2002, <http://eprint.iacr.org/2002/067.pdf>.
[MIRONOV]MIRONOV，I.，“RC4的随机洗牌”（并非如此），《密码学进展——2002年密码学：第22届国际密码学年会》，2002年8月<http://eprint.iacr.org/2002/067.pdf>.
[MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 Keystream Generator", Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques, May 2005.
[MANTIN05]Mantin，I.，“预测和区分对RC4密钥流生成器的攻击”，《密码学进展——欧洲密码2005年：第24届国际密码技术理论与应用年会》，2005年5月。
Author's Address
作者地址
Ben Harris 2a Eachard Road CAMBRIDGE CB3 0HY UNITED KINGDOM
英国剑桥CB3 0HY艾查德路2a号本哈里斯酒店
EMail: bjh21@bjh21.me.uk
EMail: bjh21@bjh21.me.uk
Trademark Notice
商标公告
"RC4" and "SSH" are registered trademarks in the United States.
“RC4”和“SSH”是美国的注册商标。
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）提供。