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
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.
この文書では、セキュアシェル（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
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]）しかしながら、[RFC4253]に記載されているように、SSHトランスポートプロトコルの対称部分にいくつかのセキュリティ上の問題を同定しました。例えば、[RFC4253]で指定された暗号化モードが選択平文プライバシー攻撃に対して脆弱です。十分な頻度で再 - 合わせていない場合はさらに、SSHトランスポートプロトコルは、ペイロードデータに関する情報を漏らすことがあります。この後者の特性に関係なく、暗号化モードが使用されているものの真実です。
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]で、ベラー、河野、およびNamprempreは、それが証明可能選択平文、選択暗号文、および反応攻撃に対してプライバシーと整合性を維持するように、SSHトランスポートプロトコルの対称部分を変更する方法を示しています。この文書では、[BKN2、BKN1]に記載の勧告をインスタンス化します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The used data types and terminology are specified in the architecture document [RFC4251].
使用されるデータ型との用語は、アーキテクチャドキュメント[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 underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or vice versa.
このセクションでは、2件の勧告を行います。非公式に、最初の推薦は、MACタグを介して可能情報漏洩から保護するために意図され、そして第二の推薦は、ブロック暗号によって可能情報漏洩から保護することを意図しています。基礎となるブロック暗号及び暗号化されたパケットの長さのブロック長に応じて、最初の推薦が第二の推薦に取って代わるか、またはその逆もできることに留意されたいです。
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）の（ビット）のブロック長とします。 Lが少なくとも128である場合、次いで、リキー後、SSHの実装では、再び再入力する前に、2つ以上の**（L / 4）のブロックを暗号化するべきではありません。 Lが128以上である場合には、SSHの実装はまた、2つ以上の**（L / 4）のブロックを受信する前にキーの再生成を強制することを試みるべきです。 Lは128未満である場合、すべての2 **（L / 4）ブロックをリキーには余りにも高価かもしれないが、その後、（例えば3DES、Blowfishの、CAST-128、およびIDEAなどの古い暗号の場合です）送信されたデータのすべてのギガバイトのために少なくとも一度リキー：SSH実装は[RFC4253]の元の推奨に従うようにするために依然として推奨されます。
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ビットのブロックとラインダール）は、次いで、セクション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).
SSH接続の各方向の暗号化方法が互いに独立して実行する必要がある[RFC4253]から呼び出して暗号化が有効である場合に、パケット長、パディング長は、各パケットのペイロード、およびパディングフィールドを使用して暗号化されなければなりません選択した方法。さらに、暗号のブロックサイズは、すべての場合である（より大きいまたは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
192ビットの鍵AES256-CTR推奨AES 128ビット鍵AES192-CTR推奨AESとSDCTRモードでAES128-CTR推奨AES（ラインダール）、SDCTRモードで256ビットの鍵3DES-CTR推奨三キー3DESとblowfish- CTRオプションフグSDCTRモードtwofish128-CTRオプションTwofishはSDCTRモードでは、128ビットの鍵twofish192-CTRオプションTwofishは192ビットの鍵twofish256-CTRオプションTwofishはSDCTRモードで256ビットの鍵serpent128-CTRオプション蛇、ととSDCTRモードCAST128-CTR OPTIONAL CAST-128 SDCTRモードでは、128ビットキーの256ビット鍵考え-CTR OPTIONAL IDEAと192ビット鍵serpent256-CTR OPTIONAL蛇128ビット鍵serpent192-CTR OPTIONAL蛇
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.
-ctr <暗号>ラベルは、<暗号>ブロック暗号は、「ステートフル・復号カウンタ」（SDCTR）モードで使用されることを示します。 Lはビット単位<暗号>のブロック長とします。ステートフル・復号カウンタモードでは、送信者と受信者の両方が、Xの初期値は、初期IVでなければならない内部LビットカウンタXを維持する（[RFC4253]のセクション7.2で計算されるように）Lビットの符号なしとして解釈ネットワークバイト順の整数。 X =（2 ** L）-1、次いで「増分X」は「0にXを設定する」の伝統的な意味を持っている場合私たちは、<X>が意味する表記を使用し、「ネットワークバイトオーダーでLビット列にXを変換します。」当然のことながら、実装は内部値Xが格納されている方法が異なっていてもよいです。例えば、実装は、複数の符号なし32ビットカウンタとしてXを格納してもよいです。
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 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.
（P1は、P2が、...、Pnが長さLの各ブロックである場合）、暗号化は、最初の<X>と<暗号>を暗号化し、パケットP = P1 || P2 || ... || Pnとを暗号化するために取得しますブロックB1。ブロックB1は、次いで、暗号文ブロックC1を生成するP1とXORされます。カウンタXがないことに留意されたいカウンタXがインクリメントされ、プロセス全体暗号文C = C1 || C2 || ... || CnがパケットPに対応を生成するために、後続の各ブロックに対して繰り返されます暗号文に含まれています。また、キーストリームは、事前に計算できることに注意して、その暗号化が並列化です。
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.
C1 || C2が|| ... ||（またXの独自のコピーを維持する）CN、復号が最初に<X>と<暗号>のコピーを暗号化=暗号文Cを復号化するために、次に、ブロックB1を生成ししますC1へのXOR 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] 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」方法は、キーの最初の8つのバイトは、最初の暗号化に使用される3つのキーのトリプルDES（暗号化解読暗号化）、復号化のための次の8バイト、次の8バイトを使用し最後の暗号化のために。これは、（168ビットが実際に使用された）鍵データの24バイトを必要とします。ブロックサイズは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.)
「ふぐ-CTR」法は、256ビットの鍵[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.
"serpent128-CTR" 法は、128ビットのキーで[SERPENT]蛇ブロック暗号を使用します。ブロックサイズは16バイトです。
The "serpent192-ctr" method uses Serpent with 192-bit keys.
「serpent192-CTR」方式は、192ビットキーで蛇を使用しています。
The "serpent256-ctr" method uses Serpent with 256-bit keys.
「serpent256-CTR」方式は、256ビットキーで蛇を使用しています。
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block size is 8 bytes.
"アイデア-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ビットキー[RFC2144]とCAST-128暗号化を使用します。ブロックサイズは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).
例えば（攻撃者は攻撃の特定の種類を使用してSSHトランスポートプロトコルの対称部分を破ることができる場合：[BKN1、BKN2]の文脈における「証明」の概念が実践指向の還元主義セキュリティのものであることに注意してください、選択暗号文攻撃）、その後、攻撃者はまた、トランスポートプロトコルの基礎となる構成要素（例えば、基礎となるブロック暗号や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- 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.
注意また、その暗号は、多くの場合、アプリケーションの全体的なセキュリティの唯一の小さな（しかし重要な）役割を果たしています。 SSHトランスポートプロトコルの場合、アプリケーションは、この文書に記載されたとおりにSSHプロトコルの対称部分を実装する場合でも、アプリケーションはアプリケーション、悪質な例として、（非プロトコルに基づく攻撃に対して脆弱であり得ます）保護されていないファイルに平文で暗号化キーを保存することがあります。これらのメソッドを実装するアプリケーションを開発する際にその結果、本明細書に記載の方法は、セキュリティの証明が付属していても、開発者は注意を実行する必要があります。
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は、2件のキー更新の勧告を行う：（1）少なくとも一回毎に2つの** 32個のパケットをリキー、及び（2）暗号化されたブロック（例えば、2 **（L / 4）ブロックであれば、特定の数の後リキーブロック暗号のブロック長L）は、少なくとも128ビットです。勧告のための動機は、（1）及び（2）異なっている、と私たちは順番に各勧告を検討します。簡単に言うと、（1）は、SSHプロトコルの基礎となるMACによる情報漏洩を防止するように設計され、および（2）は、SSHプロトコルの基本的な暗号化方式による情報漏洩から保護するために設計されています。 （1）（2）又はその逆の推奨に取って代わることができる暗号化方式のブロック長Lとパケットごとに暗号化ブロックの数、勧告に応じて、ご注意ください。
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パケットをリキーべきであると述べています。以上2つの** 32パケットが暗号化され、rekeyingsの間でSSHトランスポートプロトコルによってMACedされている場合は、SSHトランスポートプロトコルは、再生および再発注攻撃に対して脆弱になることがあります。これは、敵対者が複数回同じメッセージを受け入れるか、順不同でメッセージを受け入れるように受信機を説得することができることを意味します。また、下層のMACプロトコルのペイロードデータに関する情報を漏洩し始めることができます。より詳細には、敵対者は、（[RFC4253]のセクション4.4を参照）は、同じ32ビットのシーケンス番号とMACedれた2つのパケットに関連付けられたMACの間の衝突を探し。衝突が発見された場合には、これら二つの暗号文に関連付けられたペイロードデータは、おそらく同じです。この問題は関係なく、基本的な暗号化方式がどのように安全なの発生することに注意してください。また、暗号化しMACingとランダムパディングを使用する前に、ペイロードデータを圧縮するものの、基本的な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）32ビット以上の長SSHトランスポートプロトコルのシーケンス番号を作ることであろう。この文書では、そうすることがSSHプロトコルの旧バージョンとの相互運用性を妨げる可能性があるため、シーケンス番号の長さを増加させる示唆していません。推薦の別の代替は、（1）のような、別のMACへの基本的なHMACから切り替えることであろう
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の実装は、同じキー（と仮定Lであるが、少なくとも128）と2つ以上**（L / 4）のブロックを暗号化する前に、リキーべきであると述べています。この勧告は、暗号化方式の基礎となるブロック暗号に対する誕生日の攻撃のリスクを最小限に抑えるように設計されています。敵は、同じキーを持つ約2 **（L / 2）メッセージを暗号化するために許可されている場合たとえば、ステートフル・復号化カウンタモードに対する理論的なプライバシーの攻撃があります。それはので実装は非常に大きなブロック長との安全なブロック暗号を使用することが推奨され、これらの誕生日攻撃です。また、（2）勧告は同じキーで2つの以上** Lブロックを暗号化するから暗号化を保護するように設計されています。ここでの動機は、暗号化は、同じキーで2つの以上** Lブロックを暗号化するためにSDCTRモードを使用した場合、その後、暗号化は、キーストリーム再利用しますと、キーストリームの再利用が深刻なプライバシーの攻撃[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 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.)
カウンタモードの暗号化の1つの特性は、それがメッセージがブロック暗号のブロック長の倍数に水増しされることを必要としないことです。プロトコルのネットワークの消費量を低減することができるメッセージをパディングしていないが、この文書は、パディング（1）[RFC4253]及び（2）についての正確な情報を漏洩しないでパケットの記述を変更しないようにするためにブロック暗号のブロック長の倍数であることが必要パケットのペイロードデータの長さ。 （パディングからブロック暗号があるため（1）ここではその勧告をしないで、16バイトのブロックを使用している場合でものみ8バイトにいくつかのネットワークの節約があるかもしれませんが。）
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]アダムス、C.、 "CAST-128暗号化アルゴリズム"、RFC 2144、1997年5月。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]レーティネン、S.とC. Lonvick、エド。、 "セキュアシェル（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.
[シュナイアー]シュナイアー、B.、「応用暗号第二版：Cのコードでプロトコルアルゴリズムとソース」、ワイリー、1996。
[SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998.
[SERPENT]アンダーソン、R.、Biham、E.、およびクヌーセン、L.、 "蛇：高度暗号化規格のための提案"、NIST AES提案、1998。
[TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999.
[Twofishは】シュナイアー、B.、ら、「Twofishは暗号化アルゴリズム：128ビットのブロック暗号、第1版」、ワイリー、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]ベラー、M.、河野、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]ベラー、M.、河野、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]大、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ラ・ホーヤ、カリフォルニア州92093から0404
Phone: +1 858-534-8833 EMail: mihir@cs.ucsd.edu
電話：+1 858-534-8833電子メール：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ラ・ホーヤ、カリフォルニア州92093から0404
Phone: +1 858-534-8833 EMail: tkohno@cs.ucsd.edu
電話：+1 858-534-8833電子メール：tkohno@cs.ucsd.edu
Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121
エンジニアリング電気工学科ランシット校のChanathip Namprempreタマサート大学学部、クロンルアンパトゥムタニ、タイ12121
EMail: meaw@alum.mit.edu
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。