Network Working Group K. Igoe
Request for Comments: 5647 J. Solinas
Category: Informational National Security Agency
August 2009
AES Galois Counter Mode for
the Secure Shell Transport Layer Protocol
Abstract
抽象
Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol.
セキュアシェル（SSH）は、安全なリモート・ログイン・プロトコルです。 SSHは、認証、鍵の承認、機密性、およびデータ整合性サービスを提供するアルゴリズムを提供します。このドキュメントの目的は、AESガロアカウンタモードは、SSHトランスポート層プロトコルに機密性とデータの整合性の両方を提供するために使用することができる方法を示すことです。
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. Applicability Statement .........................................3
4. Properties of Galois Counter Mode ...............................3
4.1. AES GCM Authenticated Encryption ...........................3
4.2. AES GCM Authenticated Decryption ...........................3
5. Review of Secure Shell ..........................................4
5.1. Key Exchange ...............................................4
5.2. Secure Shell Binary Packets ................................5
6. AES GCM Algorithms for Secure Shell .............................6
6.1. AEAD_AES_128_GCM ...........................................6
6.2. AEAD_AES_256_GCM ...........................................6
6.3. Size of the Authentication Tag .............................6
7. Processing Binary Packets in AES-GCM Secure Shell ...............7
7.1. IV and Counter Management ..................................7
7.2. Formation of the Binary Packet .............................7
7.3. Treatment of the Packet Length Field .......................8
8. Security Considerations .........................................8
8.1. Use of the Packet Sequence Number in the AT ................8
8.2. Non-Encryption of Packet Length ............................8
9. IANA Considerations .............................................9
10. References ....................................................10
10.1. Normative References .....................................10
Galois Counter Mode (GCM) is a block-cipher mode of operation that provides both confidentiality and data-integrity services. GCM uses counter mode to encrypt the data, an operation that can be efficiently pipelined. Further, GCM authentication uses operations that are particularly well suited to efficient implementation in hardware, making it especially appealing for high-speed implementations or for implementations in an efficient and compact circuit. The purpose of this document is to show how GCM with either AES-128 or AES-256 can be integrated into the Secure Shell Transport Layer Protocol [RFC4253].
ガロアカウンタモード（GCM）は、機密性とデータ整合性の両方のサービスを提供し、操作のブロック暗号モードです。 GCMは、データを暗号化するために効率的にパイプライン化することができる動作をカウンタモードを使用します。さらに、GCM認証は、特に高速実装のために、または効率的でコンパクトな回路に実装するための魅力的な作り、ハードウェアで効率的な実装に特に適している操作を使用します。このドキュメントの目的は、AES-128またはAES-256のいずれかとのGCMはセキュアシェルトランスポート層プロトコル[RFC4253]に統合することができる方法を示すことです。
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]に記載されているように解釈されます。
Using AES-GCM to provide both confidentiality and data integrity is generally more efficient than using two separate algorithms to provide these security services.
機密性とデータの整合性の両方を提供するために、AES-GCMを使用すると、一般的にこれらのセキュリティサービスを提供するために2つの別々のアルゴリズムを使用するよりも効率的です。
Galois Counter Mode (GCM) is a mode of operation for block ciphers that provides both confidentiality and data integrity. National Institute of Standards and Technology (NIST) Special Publication SP 800 38D [GCM] gives an excellent explanation of Galois Counter Mode. In this document, we shall focus on AES GCM, the use of the Advanced Encryption Algorithm (AES) in Galois Counter Mode. AES-GCM is an example of an "algorithm for authenticated encryption with associated data" (AEAD algorithm) as described in [RFC5116].
ガロア・カウンタ・モード（GCM）は、機密性、データ完全性の両方を提供するブロック暗号の動作モードです。アメリカ国立標準技術研究所（NIST）特別出版SP 800 38D [GCM]はガロアカウンタモードの優れた解説を提供します。この文書では、我々はAES GCM、ガロアカウンタモードでの高度な暗号化アルゴリズム（AES）を使用することに焦点を当てるものとします。 [RFC5116]に記載されているようにAES-GCMは、（AEADアルゴリズム）「に関連するデータと認証された暗号化アルゴリズム」の一例です。
An invocation of AES GCM to perform an authenticated encryption has the following inputs and outputs:
認証された暗号化を実行するためのAES GCMの呼び出しは、以下の入力と出力があります。
GCM Authenticated Encryption
GCM認証暗号
Inputs:
octet_string PT ; // Plain Text, to be both
// authenticated and encrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated but not encrypted
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Outputs: octet_string CT; // Cipher Text octet_string AT; // Authentication Tag
出力：OCTET_STRING CT; AT //暗号文OCTET_STRING。 //認証タグ
Note: in [RFC5116], the IV is called the nonce.
注意：[RFC5116]で、IVはナンスと呼ばれています。
For a given block-cipher key BK, it is critical that no IV be used more than once. Section 7.1 addresses how this goal is to be achieved in secure shell.
与えられたブロック暗号鍵BKの場合、IVを複数回使用しないことが重要です。この目標がどのように節7.1のアドレスは、セキュアシェルで達成されます。
An invocation of AES GCM to perform an authenticated decryption has the following inputs and outputs:
認証された復号化を実行するAES GCMの呼び出しは、以下の入力および出力を有します。
GCM Authenticated Decryption
GCM認証済み暗号解読
Inputs:
octet_string CT ; // Cipher text, to be both
// authenticated and decrypted
octet_string AAD; // Additional Authenticated Data,
// authenticated only
octet_string AT; // Authentication Tag
octet_string IV; // Initialization Vector
octet_string BK; // Block Cipher Key
Output: Failure_Indicator; // Returned if the authentication tag // is invalid octet_string PT; // Plain Text, returned if and only if // the authentication tag is valid
出力：Failure_Indicator。 //認証タグ//が無効OCTET_STRINGのPTである場合に返されます。 //プレーンテキスト、認証タグが有効である場合にのみ、//場合に返さ
AES-GCM is prohibited from returning any portion of the plaintext until the authentication tag has been validated. Though this feature greatly simplifies the security analysis of any system using AES-GCM, this creates an incompatibility with the requirements of secure shell, as we shall see in Section 7.3.
AES-GCMは、認証タグが検証されるまでは平文の任意の部分を返してから禁止されています。この機能は大幅にAES-GCMを使用して任意のシステムのセキュリティ分析を簡素化しますが、我々は7.3節で見るように、これは、セキュアシェルの要件との非互換性を作成します。
The goal of secure shell is to establish two secure tunnels between a client and a server, one tunnel carrying client-to-server communications and the other carrying server-to-client communications. Each tunnel is encrypted, and a message authentication code is used to ensure data integrity.
セキュアシェルの目的は、クライアントとサーバの間の2つの安全なトンネル、クライアントとサーバの通信および他の搬送サーバからクライアントへの通信を搬送する1つのトンネルを確立することです。各トンネルは暗号化され、メッセージ認証コードは、データの整合性を保証するために使用されます。
These tunnels are initialized using the secure shell key exchange protocol as described in Section 7 of [RFC4253]. This protocol negotiates a mutually acceptable set of cryptographic algorithms and produces a secret value K and an exchange hash H that are shared by the client and server. The initial value of H is saved for use as the session_id.
[RFC4253]のセクション7で説明したようにこれらのトンネルは、セキュアシェル鍵交換プロトコルを使用して初期化されます。このプロトコルは、暗号アルゴリズムの相互に受け入れ可能なセットをネゴシエートし、秘密値Kと、クライアントとサーバで共有される交換ハッシュHを生成します。 Hの初期値は、session_idのとして使用するために保存されます。
If AES-GCM is selected as the encryption algorithm for a given tunnel, AES-GCM MUST also be selected as the Message Authentication Code (MAC) algorithm. Conversely, if AES-GCM is selected as the MAC algorithm, it MUST also be selected as the encryption algorithm.
AES-GCMが与えトンネルの暗号化アルゴリズムとして選択された場合、AES-GCMは、メッセージ認証コード（MAC）アルゴリズムのように選択しなければなりません。 AES-GCMがMACアルゴリズムとして選択された場合、逆に、それはまた、暗号化アルゴリズムとして選択されなければなりません。
As described in Section 7.2 of [RFC4253], a hash-based key derivation function (KDF) is applied to the shared secret value K to generate the required symmetric keys. Each tunnel gets a distinct set of symmetric keys. The keys are generated as shown in Figure 1. The sizes of these keys varies depending upon which cryptographic algorithms are being used.
[RFC4253]のセクション7.2に記載されているように、ハッシュベースの鍵導出関数（KDF）が必要な対称キーを生成するために共有秘密値Kに適用されます。各トンネルは、対称鍵の別個のセットを取得します。これらのキーのサイズは暗号化アルゴリズムが使用されているかに依存して変化する、図1に示すように、キーが生成されます。
Initial IV Client-to-Server HASH( K || H ||"A"|| session_id) Server-to-Client HASH( K || H ||"B"|| session_id) Encryption Key Client-to-Server HASH( K || H ||"C"|| session_id) Server-to-Client HASH( K || H ||"D"|| session_id) Integrity Key Client-to-Server HASH( K || H ||"E"|| session_id) Server-to-Client HASH( K || H ||"F"|| session_id)
初期IVクライアントからサーバへのHASH（K || H || "A" ||のsession_id）サーバーからクライアントへのHASH（K || H || "B" ||のsession_id）暗号化キークライアントとサーバーHASH （K || H || "C" || SESSION_ID）サーバーからクライアントへHASH（K || H || "D" || SESSION_ID）インテグリティキークライアントとサーバHASH（K || H ||」 E "||のsession_id）サーバーからクライアントへのHASH（K || H ||" F "|| SESSION_ID）
Figure 1: Key Derivation in Secure Shell
図1：Secure Shellでの鍵の導出
As we shall see below, SSH AES-GCM requires a 12-octet Initial IV and an encryption key of either 16 or 32 octets. Because an AEAD algorithm such as AES-GCM uses the encryption key to provide both confidentiality and data integrity, the integrity key is not used with AES-GCM.
私たちは以下を参照するものとして、SSH AES-GCMは、12オクテットの初期IVおよび16または32オクテットの暗号化キーが必要です。このようAES-GCMとしてAEADアルゴリズムは、機密性とデータの整合性の両方を提供するために、暗号化キーを使用しているため、整合性キーはAES-GCMでは使用されません。
Either the server or client may at any time request that the secure shell session be rekeyed. The shared secret value K, the exchange hash H, and all the above symmetric keys will be updated. Only the session_id will remain unchanged.
サーバーまたはクライアントは、いつでも要求にセキュアシェルセッションは、リキーすることができるという。共有シークレット値K、交換ハッシュH、および上記のすべての対称キーが更新されます。唯一のSESSION_IDは変更されません。
Upon completion of the key exchange protocol, all further secure shell traffic is parsed into a data structure known as a secure shell binary packet as shown below in Figure 2 (see also Section 6 of [RFC4253]).
図2に、以下に示すように、鍵交換プロトコルの完了時に、すべてのさらなるセキュアシェルトラフィックが（また、[RFC4253]のセクション6を参照）、セキュアシェルバイナリパケットと呼ばれるデータ構造に解析されます。
uint32 packet_length; // 0 <= packet_length < 2^32 byte padding_length; // 4 <= padding_length < 256 byte[n1] payload; // n1 = packet_length-padding_length-1 byte[n2] random_padding; // n2 = padding_length byte[m] mac; // m = mac_length
UINT32のpacket_length。 // 0 <= packet_length <2 ^ 32バイトするpadding_length。 // 4 <=するpadding_length <256バイト[N1]ペイロード。 // N1 = packet_length-するpadding_length-1バイト[N2] random_padding。 // N2 =するpadding_lengthバイト[M]マック。 //メートル= mac_length
Figure 2: Structure of a Secure Shell Binary Packet
図2：セキュアシェルバイナリパケットの構造
The authentication tag produced by AES-GCM authenticated encryption will be placed in the MAC field at the end of the secure shell binary packet.
AES-GCM認証暗号化によって生成される認証タグは、セキュアシェルバイナリパケットの終わりにMACフィールドに配置されます。
AEAD_AES_128_GCM is specified in Section 5.1 of [RFC5116]. Due to the format of secure shell binary packets, the buffer sizes needed to implement AEAD_AES_128_GCM are smaller than those required in [RFC5116]. Using the notation defined in [RFC5116], the input and output lengths for AEAD_AES_128_GCM in secure shell are as follows:
AEAD_AES_128_GCMは、[RFC5116]のセクション5.1で指定されています。セキュアシェルバイナリパケットのフォーマットのために、AEAD_AES_128_GCMを実装するために必要なバッファサイズは、[RFC5116]に必要なものよりも小さいです。次のように[RFC5116]で定義された表記を使用して、セキュアシェルでAEAD_AES_128_GCMの入力および出力長さです。
PARAMETER Meaning Value
パラメータ意味値
K_LEN AES key length 16 octets P_MAX maximum plaintext length 2^32 - 32 octets A_MAX maximum additional 4 octets authenticated data length N_MIN minimum nonce (IV) length 12 octets N_MAX maximum nonce (IV) length 12 octets C_MAX maximum cipher length 2^32 octets
K_LEN AESキーの長さ16オクテットP_MAX最大平文長さ2 ^ 32 - A_MAX最大追加の4つのオクテットが2 ^ 32オクテットのデータ長N_MIN最小ナンス（IV）長さ12オクテットN_MAX最大ナンス（IV）長さ12オクテットC_MAX最大暗号長を認証32オクテット
AEAD_AES_256_GCM is specified in Section 5.2 of [RFC5116]. Due to the format of secure shell binary packets, the buffer sizes needed to implement AEAD_AES_256_GCM are smaller than those required in [RFC5116]. Using the notation defined in [RFC5116], the input and output lengths for AEAD_AES_256_GCM in secure shell are as follows:
AEAD_AES_256_GCMは、[RFC5116]のセクション5.2で指定されています。セキュアシェルバイナリパケットのフォーマットのために、AEAD_AES_256_GCMを実装するために必要なバッファサイズは、[RFC5116]に必要なものよりも小さいです。次のように[RFC5116]で定義された表記を使用して、セキュアシェルでAEAD_AES_256_GCMの入力および出力長さです。
PARAMETER Meaning Value
パラメータ意味値
K_LEN AES key length 32 octets P_MAX maximum plaintext length 2^32 - 32 octets A_MAX maximum additional 4 octets authenticated data length N_MIN minimum nonce (IV) length 12 octets N_MAX maximum nonce (IV) length 12 octets C_MAX maximum cipher length 2^32 octets
K_LEN AESキーの長さ32オクテットP_MAX最大平文長さ2 ^ 32 - A_MAX最大追加の4つのオクテットが2 ^ 32オクテットのデータ長N_MIN最小ナンス（IV）長さ12オクテットN_MAX最大ナンス（IV）長さ12オクテットC_MAX最大暗号長を認証32オクテット
Both AEAD_AES_128_GCM and AEAD_AES_256_GCM produce a 16-octet Authentication Tag ([RFC5116] calls this a "Message Authentication Code"). Some applications allow use of a truncated version of this tag. This is not allowed in AES-GCM secure shell. All implementations of AES-GCM secure shell MUST use the full 16-octet Authentication Tag.
AEAD_AES_128_GCMとAEAD_AES_256_GCM両方が16オクテットの認証タグ（[RFC5116]を呼び出し、この「メッセージ認証コード」）を生成します。一部のアプリケーションでは、このタグの短縮バージョンを使用することができます。これは、AES-GCMのセキュアシェルでは使用できません。 AES-GCMのセキュアシェルのすべての実装は、完全な16オクテットの認証タグを使用する必要があります。
With AES-GCM, the 12-octet IV is broken into two fields: a 4-octet fixed field and an 8-octet invocation counter field. The invocation field is treated as a 64-bit integer and is incremented after each invocation of AES-GCM to process a binary packet.
4オクテットの固定フィールドと、8オクテット呼び出しカウンタフィールド：AES-GCMを用いて、12オクテットIVは、2つのフィールドに分割されます。起動フィールドは、64ビット整数として扱われ、バイナリ・パケットを処理するためにAES-GCMの各呼び出しの後にインクリメントされます。
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
Figure 3: Structure of an SSH AES-GCM Nonce
図3：SSH AES-GCMノンスの構造
AES-GCM produces a keystream in blocks of 16-octets that is used to encrypt the plaintext. This keystream is produced by encrypting the following 16-octet data structure:
AES-GCMは、平文を暗号化するために使用される16オクテットのブロックにおけるキーストリームを生成します。このキーストリームは、次の16オクテットのデータ構造を暗号化することによって製造されます。
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
uint32 block_counter; // 4 octets
Figure 4: Structure of an AES Input for SSH AES-GCM
図4：SSH AES-GCMのためのAES入力の構造
The block_counter is initially set to one (1) and incremented as each block of key is produced.
block_counterは、最初にオン（1）に設定され、キーの各ブロックが生成されるようにインクリメントされます。
The reader is reminded that SSH requires that the data to be encrypted MUST be padded out to a multiple of the block size (16-octets for AES-GCM).
読者は、SSHは暗号化すべきデータがブロックサイズ（AES-GCMのための16オクテット）の倍数にパディングされなければならないことを必要とすることに留意します。
In AES-GCM secure shell, the inputs to the authenticated encryption are:
AES-GCMのセキュアシェルでは、認証された暗号化への入力は、次のとおりです。
PT (Plain Text) byte padding_length; // 4 <= padding_length < 256 byte[n1] payload; // n1 = packet_length-padding_length-1 byte[n2] random_padding; // n2 = padding_length AAD (Additional Authenticated Data) uint32 packet_length; // 0 <= packet_length < 2^32 IV (Initialization Vector) As described in section 7.1. BK (Block Cipher Key) The appropriate Encryption Key formed during the Key Exchange.
PT（テキスト）バイトするpadding_length。 // 4 <=するpadding_length <256バイト[N1]ペイロード。 // N1 = packet_length-するpadding_length-1バイト[N2] random_padding。 // N2 =するpadding_lengthのAAD（追加認証されたデータ）UINT32 packet_length。 // 0 <= packet_length <2 ^ 32 IV（初期化ベクトル）のセクション7.1で説明したように。 BK（ブロック暗号鍵）鍵交換の間に形成された適切な暗号化キー。
As required in [RFC4253], the random_padding MUST be at least 4 octets in length but no more than 255 octets. The total length of the PT MUST be a multiple of 16 octets (the block size of AES). The binary packet is the concatenation of the 4-octet packet_length, the cipher text (CT), and the 16-octet authentication tag (AT).
[RFC4253]で必要に応じて、random_paddingは、長さが少なくとも4つのオクテットが、せいぜい255個のオクテットでなければなりません。 PTの合計の長さは16個のオクテット（AESのブロックサイズ）の倍数でなければなりません。バイナリパケットは4オクテットpacket_length、暗号文（CT）、および16オクテットの認証タグ（AT）の連結です。
Section 6.3 of [RFC4253] requires that the packet length, padding length, payload, and padding fields of each binary packet be encrypted. This presents a problem for SSH AES-GCM because:
[RFC4253]のセクション6.3は各バイナリパケットのパケット長、パディング長、ペイロード、およびパディングフィールドを暗号化することを必要とします。これは、SSH AES-GCMのための問題を提起します：
1) The tag cannot be verified until we parse the binary packet.
我々はバイナリパケットを解析するまで1）タグを検証することはできません。
2) The packet cannot be parsed until the packet_length has been decrypted.
packet_lengthが復号化されるまで、2）パケットを解析することができません。
3) The packet_length cannot be decrypted until the tag has been verified.
タグが検証されるまで、3）packet_lengthを解読することはできません。
When using AES-GCM with secure shell, the packet_length field is to be treated as additional authenticated data, not as plaintext. This violates the requirements of [RFC4253]. The repercussions of this decision are discussed in the following Security Considerations section.
セキュアシェルとAES-GCMを使用する場合、packet_lengthフィールドがない平文として、付加的な認証データとして扱われるべきです。これは、[RFC4253]の要件に違反します。この決定の影響は、次のセキュリティの考慮事項のセクションで説明されています。
The security considerations in [RFC4251] apply.
[RFC4251]のセキュリティの考慮事項が適用されます。
[RFC4253] requires that the formation of the AT involve the packet sequence_number, a 32-bit value that counts the number of binary packets that have been sent on a given SSH tunnel. Since the sequence_number is, up to an additive constant, just the low 32 bits of the invocation_counter, the presence of the invocation_counter field in the IV ensures that the sequence_number is indeed involved in the formation of the integrity tag, though this involvement differs slightly from the requirements in Section 6.4 of [RFC4253].
[RFC4253]はATの形成は、パケットSEQUENCE_NUMBER、所与SSHトンネル上で送信されたバイナリ・パケットの数をカウントする32ビット値を含むことを必要とします。 SEQUENCE_NUMBERは、加法定数まで、invocation_counterのちょうど下位32ビットであるため、IVにおけるinvocation_counterフィールドの存在は、この関与が若干異なるもののSEQUENCE_NUMBERが実際に、完全性タグの形成に関与していることを確実にします[RFC4253]のセクション6.4の要求事項。
As discussed in Section 7.3, there is an incompatibility between GCM's requirement that no plaintext be returned until the authentication tag has been verified, secure shell's requirement that the packet length be encrypted, and the necessity of decrypting the packet length field to locate the authentication tag. This document addresses this dilemma by requiring that, in AES-GCM, the packet length field will not be encrypted but will instead be processed as additional authenticated data.
7.3節で述べたように、認証タグを検索する認証タグが確認されるまで何の平文が返されないことがGCMの要件、セキュアシェルのパケット長が暗号化されるという要件、およびパケット長フィールドを復号化する必要性との間に互換性があります。この文書では、AES-GCMで、パケット長フィールドは暗号化されませんが、代わりに、追加の認証されたデータとして処理される、ことを要求することによって、このジレンマを解決します。
In theory, one could argue that encryption of the entire binary packet means that the secure shell dataflow becomes a featureless octet stream. But in practice, the secure shell dataflow will come in bursts, with the length of each burst strongly correlated to the length of the underlying binary packets. Encryption of the packet length does little in and of itself to disguise the length of the underlying binary packets. Secure shell provides two other mechanisms, random padding and SSH_MSG_IGNORE messages, that are far more effective than encrypting the packet length in masking any structure in the underlying plaintext stream that might be revealed by the length of the binary packets.
理論的には、1は全体のバイナリパケットの暗号化は、セキュアシェルのデータフローが特徴のオクテットストリームになっていることを意味主張することができます。しかし実際には、セキュアシェルのデータフローを強く根本的なバイナリパケットの長さに相関する各バーストの長さと、バーストで来ます。パケット長の暗号化は、基礎となるバイナリパケットの長さを隠すために少しそれ自体はありません。セキュアシェルは、はるかに効果的なバイナリパケットの長さによって明らかにされるかもしれない基本となる平文ストリーム内の任意の構造をマスク内のパケット長を暗号化するよりも他の二つのメカニズム、ランダムパディングとSSH_MSG_IGNOREメッセージを、提供します。
IANA added the following two entries to the secure shell Encryption Algorithm Names registry described in [RFC4250]:
IANAは、[RFC4250]に記載のセキュアシェル暗号化アルゴリズム名レジストリに次の2つのエントリを追加しました。
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
IANA added the following two entries to the secure shell MAC Algorithm Names registry described in [RFC4250]:
IANAは、[RFC4250]に記載のセキュアシェルMACアルゴリズム名レジストリに次の2つのエントリを追加しました。
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.2 |
+--------------------+-------------+
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-30D, November 2007.
、は、NIST Special Publication 800-30D、2007年11月：[GCM] Dworkin、M、 "ガロア/カウンタモード（GCM）とGMACの動作のブロック暗号モードのための勧告"。
[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月。
[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月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]マグリュー、D.、 "認証暗号化のためのインタフェースとアルゴリズム"、RFC 5116、2008年1月。
Authors' Addresses
著者のアドレス
Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency USA
ケビンM. Igoe NSA / CSS商用ソリューションセンター国家安全保障局USA
EMail: kmigoe@nsa.gov
メールアドレス：kmigoe@nsa.gov
Jerome A. Solinas National Information Assurance Research Laboratory National Security Agency USA
ジェロームA. Solinas国立情報保証研究所国家安全保障局USA
EMail: jasolin@orion.ncsc.mil
メールアドレス：jasolin@orion.ncsc.mil