[要約] 要約:RFC 4345は、SSHトランスポート層プロトコルのための改良されたArcfourモードについて説明しています。 目的:このRFCの目的は、SSHのセキュリティを向上させるために、Arcfourモードの改良を提案することです。
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)輸送層プロトコル用の改善されたArcFourモード
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).
Copyright(c)The Internet Society(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.
このドキュメントは、暗号のキースケジュールアルゴリズムの弱点を軽減するSecure Shell(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]は、安全なリモートロジンプロトコルです。これにより、輸送中のデータの機密性を提供するために、拡張可能な種類の対称暗号アルゴリズムを使用できます。基本プロトコルで指定されているアルゴリズムの1つは「ArcFour」です。これは、高速ストリーム暗号であるArcFour(RC4とも呼ばれる)の使用を指定しています。[RFC4253]が言うように、「Arcfour(およびRC4)には弱いキーに問題があり、注意して使用する必要があります。」これらの問題は、[Mantin01]でより詳細に説明されており、Cipherの内部状態が徹底的に混合されるように、キーストリームの最初の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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]アルゴリズムは、[schneier]で説明されているように、128ビットキーを使用してRC4暗号です。暗号によって生成された最初の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には2つのクラスの攻撃があります。強力な違いは、ArcFourキーストリームをストリームの開始時にランダム性と区別し、このドキュメントで定義されているアルゴリズムによって防御されます。弱い違いは、キーストリームのどの部分でも動作し、[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。and C. Lonvick、ed。、「The Secure Shell(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、ed。、「The Secure Shell(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、ed。、「The Secure Shell(SSH)Transport Layer Protocol」、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。、「Applied Cryptography Second Edition:Protocols Algorithms and Source in Code in CのCode」、John Wiley and Sons、New York、NY、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キーストリームジェネレーターの統計分析」、高速ソフトウェア暗号化:第7回国際ワークショップ、FSE 2000、2000年4月、<http://www.mindspring.com/~dmcrew/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。、「Stream Cipher RC4の分析」、M.Sc。論文、ワイズマン科学研究所、2001年、<http:// www.wisdom.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のランダムシャッフル」、暗号学の進歩 - Crypto 2002:22nd Annulational Cryptology Conference、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キーストリームジェネレーターに対する攻撃の予測と区別」、暗号化の進歩-EuroCrypt 2005:第24回暗号化技術の理論と応用に関する第24回年次国際会議、2005年5月。
Author's Address
著者の連絡先
Ben Harris 2a Eachard Road CAMBRIDGE CB3 0HY UNITED KINGDOM
ベン・ハリス2A各ロードケンブリッジCB3 0HYイギリス
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).
Copyright(c)The Internet Society(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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ(IASA)によって提供されます。