[要約] RFC 4344は、SSHのトランスポート層暗号化モードに関する仕様であり、SSHのセキュリティを向上させるための目的で作成されました。
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
安全なシェル（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).
Copyright（c）The Internet Society（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
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輸送プロトコルの対称部分は、カプセル化されたデータのプライバシーと整合性の両方を提供するように設計されています。ただし、[RFC4253]で説明されているように、研究者（[DAI、BKN1、BKN2]）は、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]では、Bellare、Kohno、およびNamprempreでは、SSHトランスポートプロトコルの対称部分を変更する方法を示しているため、選択したプレーンテキスト、Cosen-Ciphertext、および反応攻撃に対するプライバシーと整合性を保持します。このドキュメントは、[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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タグを介した可能な情報漏れから保護することを目的としており、2番目の推奨は、ブロック暗号を介して可能な情報漏れから保護することを目的としています。基礎となるブロック暗号のブロック長と暗号化されたパケットの長さに応じて、最初の推奨事項は2番目の推奨事項に取って代わる可能性があることに注意してください。
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の発信パケットに少なくとも1回は再キーを再キーする必要があります。より明確に、キーエクスチェンジの後、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の実装も、最後のRekey操作以降に2 ** 32個以上のパケットを受信する前に、再キーを試してみる必要があります。これを行うための好ましい方法は、最後のReke操作以降に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の実装は再びrekeyする前に2 **（L/4）ブロックを超えて暗号化する必要はありません。Lが少なくとも128の場合、SSH実装も2 **（L/4）ブロックを受信する前にRekeを強制しようとする必要があります。Lが128未満（3DES、BlowFish、CAST-128、IDEAなどの古い暗号の場合です）が、2 **（L/4）ブロックごとに再キーするには高すぎる場合がありますが、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ビットブロックを持つ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接続の各方向の暗号化方法は互いに独立して実行する必要があり、暗号化が有効な場合、各パケットのパケットの長さ、パディングの長さ、ペイロード、およびパディングフィールドは、暗号化する必要があることを思い出してください。選択した方法。さらに、パケットの長さ、パディングの長さ、ペイロード、およびパディングの連結の合計の長さは、暗号のブロックサイズが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
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 <cipher>が「Stateful Decryption Counter」（SDCTR）モードで使用されることを示しています。lをビットの<cipher>のブロック長とします。ステートフルデクラプトカウンターモードでは、送信者と受信機の両方が内部LビットカウンターXを維持します。Xの初期値は、L-BIT unsignedとして解釈される初期IV（[RFC4253]のセクション7.2で計算されている）でなければなりません。ネットワークバイトオーダーの整数。x =（2 ** l）-1の場合、「increment 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 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 = p1 || p2 || ... || pn（p1、p2、...、pnは長さlのそれぞれブロックです）。ブロックB1。ブロックB1はP1でXoredで、暗号文ブロックC1を生成します。その後、カウンターXが増加し、その後のブロックごとにプロセスが繰り返されて、パケットPに対応するCiphertext C = C1 || C2 || ... || CN全体を生成します。カウンターXはそうではないことに注意してくださいciphertextに含まれています。また、キーストリームは事前に計算され、暗号化が並列化可能であることに注意してください。
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を復号化するには、decryptor（xの独自のコピーも維持している）を最初に<x>のコピーを<cipher>で暗号化してブロックb1を生成し、次に生成します。Xors B1からC1から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」メソッドは、128ビットキー[AES]を備えたAES（以前のRijndael）を使用します。ブロックサイズは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」メソッドは、3キートリプルデス（エンクリプトデクリプトエンクリプト）を使用します。ここで、キーの最初の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ビットキーを備えたブローフィッシュを使用しています[Schneier]。ブロックサイズは8バイトです。（[RFC4253]の「Blowfish-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ビットキーを備えた蛇ブロック暗号[蛇]を使用します。ブロックサイズは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.
「Idea-Ctr」メソッドは、アイデアCipher [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].
このセクションは、このドキュメントで説明されている方法と推奨事項から逸脱した可能性のある結果と、セキュリティ関連の動機を実装することを理解できるように設計されています。追加の動機と議論、およびセキュリティの証明は、研究論文[BNCN1、BNKN2]に掲載されています。
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輸送プロトコルの対称部分を破ることができる場合（例えば、選択されたカイフェートテキスト攻撃）、攻撃者は、輸送プロトコルの基礎となるコンポーネントの1つ（たとえば、基礎となるブロック暗号または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プロトコルの対称部分を実装する可能性がある場合でも、アプリケーションは非プロトコルベースの攻撃に対して脆弱である可能性があります（著しい例として、アプリケーションはアプリケーションです。ClearTextの暗号化キーを保護されていないファイルに保存する可能性があります）。したがって、ここで説明する方法にセキュリティの証明が付属しているにもかかわらず、開発者はこれらの方法を実装するアプリケーションを開発する際には注意を払う必要があります。
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パケットごとに少なくとも1回は再キー、（2）暗号化されたブロックの数（例：2 **（l/4）ブロックの場合の再キーの後の再キーブロックCipherのブロック長lは少なくとも128ビットです）。推奨事項（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パケットごとに少なくとも1回は再キーを再キーする必要があると述べています。2 ** 32個以上のパケットが再キーリング間のSSHトランスポートプロトコルによって暗号化およびマッキングされている場合、SSH輸送プロトコルは攻撃の再生と再注文に対して脆弱になる可能性があります。これは、敵がレシーバーに同じメッセージを複数回受け入れるように説得したり、故障しているメッセージを受け入れるように説得できることを意味します。さらに、基礎となるMACは、プロトコルのペイロードデータに関する情報を漏らし始める可能性があります。より詳細には、敵は、同じ32ビットシーケンス番号でマッキングされた2つのパケットに関連付けられたMac間の衝突を探します（[RFC4253]のセクション4.4を参照）。衝突が見つかった場合、これらの2つの暗号文に関連付けられたペイロードデータはおそらく同じです。この問題は、基礎となる暗号化方法の安全性に関係なく発生することに注意してください。また、暗号化とマッキング前にペイロードデータを圧縮し、ランダムパディングを使用すると、基礎となるMACを介した情報漏れのリスクが低下する可能性があるが、圧縮とランダムパディングの使用は情報の漏れを妨げないことに注意してください。少なくとも2 ** 32パケットに少なくとも1回再キーをしないことを決定した実装者は、これらの問題を理解する必要があります。これらの問題については、[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 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.
推奨事項（1）に代わる1つの選択肢は、SSH輸送プロトコルのシーケンス番号を32ビット以上長くすることです。このドキュメントでは、SSHプロトコルの古いバージョンとの相互運用性を妨げる可能性があるため、シーケンス番号の長さを増やすことを示唆していません。推奨事項（1）のもう1つの代替手段は、基本的なHMACから、独自の内部カウンターを持つMacなどの別のMacに切り替えることです。プロトコルに既に存在する32ビットカウンターのため、このようなカウンターは、2 ** 32パケットごとに1回インクリメントする必要があります。
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）メッセージを暗号化することを許可されている場合、Stateful-Decryption Counter Modeに対する理論的プライバシー攻撃があります。これらの誕生日攻撃のために、実装者は、ブロックの長さが大きい安全なブロック暗号を使用することを強くお勧めします。さらに、推奨事項（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、BN1、BN2]に対して脆弱であることを示しています。このドキュメントのセクション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）の1つを使用する場合、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]のパケットの説明を変更しないように、パディングはブロックCipherのブロック長の倍数であり、（2）漏れないようにする必要があります。パケットのペイロードデータの長さ。（ブロックCipherが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).
ステートフルデクライプトカウンターモードに加えて、[BNCN1、BN2]は、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]国立標準技術研究所、「Advanced Encryption Standard（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。、「The 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] 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）輸送層プロトコル」、RFC 4253、2006年1月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996.
[Schneier] Schneier、B。、「Applied Cryptography Second Edition：Protocols Algorithms and Source in Code in 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 Proposal、1998。
[TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999.
[Twofish] Schneier、B.、et al。、「The Twofish Encryptions Algorithm：A 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バイナリパケットプロトコルの修正」、コンピューターおよび通信セキュリティに関する第9回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トランザクションの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ラホーヤ、カリフォルニア州92093-0404
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ラホーヤ、カリフォルニア州92093-0404
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 University Engineering Engineering Engineering Department Rangsit Campus、Klong Luang Pathumthani、タイ12121
EMail: meaw@alum.mit.edu
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）によって提供されます。