RFC4345 日本語訳

Network Working Group                                          B. Harris
Request for Comments: 4345                                  January 2006
Category: Standards Track

コメントを求めるワーキンググループB.ハリス要求をネットワークでつないでください: 4345 2006年1月のカテゴリ: 標準化過程

                      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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントは暗号の主要なスケジューリングアルゴリズムの弱点を緩和するSecureシェル(SSH)プロトコルにArcfour暗号を使用する方法を指定します。

1.  Introduction

1. 序論

   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.

安全なシェル(SSH)[RFC4251]は安全なリモート・ログインプロトコルです。 それは、広げることができるバラエティーの左右対称の暗号アルゴリズムの使用がトランジットで秘密性をデータに提供するのを許容します。 ベースプロトコルで指定されたアルゴリズムの1つはArcfour(また、RC4として、知られています)(速いストリーム暗号)の使用を指定する"arcfour"です。 もっとも、[RFC4253]が言うように、「Arcfour(そして、RC4)は弱いキーに関する問題を持って、慎重に使用されるべきです」。 これらの問題はさらに詳細に[MANTIN01]で説明されます、暗号の内部の状態が徹底的に複雑であることを確実にするために最初の1536バイトのkeystreamを捨てるという推薦と共に。 このドキュメントはこの推薦に続くSSHに新しい暗号アルゴリズムを指定します。

2.  Conventions Used in this Document

2. このDocumentのコンベンションUsed

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Harris                      Standards Track                     [Page 1]

RFC 4345             Improved Arcfour Modes for SSH         January 2006

ハリス標準化過程[1ページ]RFC4345はセキュアシェル (SSH)2006年1月にArcfourモードを改良しました。

3.  Applicability Statement

3. 適用性証明

   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]によって指定されたアルゴリズムは代わりに使用されるべきです。

4.  Algorithm Definitions

4. アルゴリズム定義

   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.

128ビットのキーを使用して、"arcfour128"アルゴリズムは[シュナイアー]で説明されるようにRC4暗号です。 暗号で発生する最初の1536バイトのkeystreamを捨てなければなりません、そして、keystreamの1537番目のバイトを使用して、最初のコード化されたパケットの最初のバイトをコード化しなければなりません。

   The "arcfour256" algorithm is the same, but uses a 256-bit key.

"arcfour256"アルゴリズムは、同じですが、256ビットのキーを使用します。

5.  Security Considerations

5. セキュリティ問題

   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.

捨てられたバイトのkeystreamは秘密にしなければならなくて、ネットワークの上に伝えられてはいけません。 これらのバイトのコンテンツはキーの情報を明らかにするかもしれません。

   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.

攻撃の2つのクラスが[ミロノフ]で説明されたArcfourにあります。 強いdistinguishersは流れの始めで偶発性とArcfour keystreamを区別して、アルゴリズムで本書では定義されていることに対して防御されます。 弱いdistinguishersはkeystreamのどんな部分も作動させることができます、そして、[FMcG]と[MANTIN05]で説明される中で最も良い方は複数の、そして、異なったkeystreamsからのデータを使用できます。この結果は別々のArcfour keystreamsで十分何回も同じデータ(例えば、パスワード)をコード化するのがそれに関して敵に情報を漏らすことができる場合があるくらいのことです。 その結果、大容量パスワードが接続を認証したのでArcfour(ここで説明されたフォームか[RFC4251]で説明されたそれの)が使用されないのは、RECOMMENDEDです。

6.  IANA Considerations

6. IANA問題

   The IANA has assigned the Encryption Algorithm Names "arcfour128" and
   "arcfour256" in accordance with [RFC4250].

[RFC4250]に従って、IANAはEncryption Algorithm Names"arcfour128"と"arcfour256"を割り当てました。

Harris                      Standards Track                     [Page 2]

RFC 4345             Improved Arcfour Modes for SSH         January 2006

ハリス標準化過程[2ページ]RFC4345はセキュアシェル (SSH)2006年1月にArcfourモードを改良しました。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC4250]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250, January 2006.

[RFC4250] レーティネンとS.とC.Lonvick、エド、「安全なシェル(セキュアシェル (SSH))プロトコル規定番号」、RFC4250、1月2006日

   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

[RFC4251] YlonenとT.とC.Lonvick、エド、「安全なシェル(セキュアシェル (SSH))プロトコル構造」、RFC4251、1月2006日

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006

[RFC4253] YlonenとT.とC.Lonvick、エド、「安全なシェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、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.、河野、T.、およびC.Namprempre、「安全なシェル(セキュアシェル (SSH))トランスポート層暗号化モード」、RFC4344、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.

[シュナイアー]シュナイアー、B.、「適用された暗号第2版:」 「Cのコードのプロトコルアルゴリズムとソース」とジョン・ワイリーとソンス、ニューヨーク(ニューヨーク)1996。

7.2.  Informative References

7.2. 有益な参照

   [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.マグリュー、「申し立てられたRC4 Keystreamジェネレータの統計分析」、速いソフトウェア暗号化: 第7国際ワークショップ、FSE2000、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.wisdom.weizmann.ac.il/~itsik/RC4/書類/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>.

[ミロノフ]ミロノフ、I.、「RC4"の(Not So)の無作為のシャッフル、暗号理論における進歩--暗号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(「RC4 Keystreamジェネレータに対する攻撃を予測して、区別する」I.)はEUROCRYPT2005年に暗号理論--進みます: 理論に関する第24年に一度の国際会議と暗号のテクニック、2005年5月のアプリケーション。

Harris                      Standards Track                     [Page 3]

RFC 4345             Improved Arcfour Modes for SSH         January 2006

ハリス標準化過程[3ページ]RFC4345はセキュアシェル (SSH)2006年1月にArcfourモードを改良しました。

Author's Address

作者のアドレス

   Ben Harris
   2a Eachard Road
   CAMBRIDGE
   CB3 0HY
   UNITED KINGDOM

ベン・ハリス・2a Eachard道路ケンブリッジCB3 0HYイギリス

   EMail: bjh21@bjh21.me.uk

メール: bjh21@bjh21.me.uk

Trademark Notice

商標表示

   "RC4" and "SSH" are registered trademarks in the United States.

「RC4"と「セキュアシェル (SSH)」は合衆国の登録商標です。」

Harris                      Standards Track                     [Page 4]

RFC 4345             Improved Arcfour Modes for SSH         January 2006

ハリス標準化過程[4ページ]RFC4345はセキュアシェル (SSH)2006年1月にArcfourモードを改良しました。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Harris                      Standards Track                     [Page 5]

ハリス標準化過程[5ページ]