[要約] RFC 5647は、Secure Shell（SSH）トランスポート層プロトコルのためのAES Galois Counter Mode（GCM）に関する仕様です。このRFCの目的は、SSHセッションのセキュリティを向上させるために、GCMを使用した暗号化と認証を提供することです。
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
安全なシェル輸送層プロトコル用のAESガロアカウンターモード
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.
Secure Shell（SSH）は、安全なリモートロジンプロトコルです。SSHは、認証、主要な合意、機密性、およびデータ統合サービスを提供するアルゴリズムを提供します。このドキュメントの目的は、AES Galoisカウンターモードを使用して、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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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].
Galois Counter Mode（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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].
Galoisカウンターモード（GCM）は、機密性とデータの整合性の両方を提供するブロック暗号の動作モードです。国立標準技術研究所（NIST）Special Publication SP 800 38D [GCM]は、ガロアカウンターモードの優れた説明を提供します。このドキュメントでは、ガロアカウンターモードでの高度な暗号化アルゴリズム（AES）の使用AES GCMに焦点を当てます。AES-GCMは、[RFC5116]で説明されているように、「関連データを使用した認証された暗号化のアルゴリズム」（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
Note: in [RFC5116], the IV is called the nonce.
注：[RFC5116]では、IVはNonCeと呼ばれます。
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
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つはクライアントからサーバーへの通信を運ぶトンネル、もう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クライアントからサーバーへのハッシュ（k || h || "a" || session_id）サーバーからクライアントハッシュ（k || h || "b" || session_id）暗号化キークライアントからサーバーハッシュ（k || h || "c" || session_id）サーバーからクライアントハッシュ（k || h || "d" || session_id）整合性キークライアントからサーバーへのハッシュ（k || h || "e "|| session_id）サーバーからクライアントハッシュ（k || h ||" f "|| session_id）
Figure 1: Key Derivation in Secure Shell
図1：安全なシェルのキー導出
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アルゴリズムは暗号化キーを使用して機密性とデータの整合性の両方を提供するため、Integrityキーは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、Exchange Hash 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
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認証暗号化によって生成された認証タグは、Secure Shellバイナリパケットの最後に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
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
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-OCTET認証タグ（[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.
AES-GCMを使用すると、12-OCTET IVは2つのフィールドに分割されます：4-OCTET固定フィールドと8オクテットの呼び出しカウンターフィールド。呼び出しフィールドは、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 nonceの構造
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つ（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（プレーンテキスト）BYTE PADDING_LENGTH;// 4 <= padding_length <256 byte [n1]ペイロード;// n1 = packet_length-padding_length-1 byte [n2] random_padding;// n2 = padding_length aad（追加の認証データ）uint32 packet_length;// 0 <= packet_length <2^32 IV（初期化ベクトル）セクション7.1で説明されています。BK（Cipherキーブロック）キー交換中に形成された適切な暗号化キー。
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オクテット（AEのブロックサイズ）の倍数でなければなりません。バイナリパケットは、4-OCTET packet_length、cipherテキスト（CT）、および16-OCTET認証タグ（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.
2) packet_lengthが復号化されるまで、パケットを解析することはできません。
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.
Secure Shellを使用して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の形成には、特定のSSHトンネルで送信されたバイナリパケットの数をカウントする32ビット値であるパケットSequence_Numberを含むことが必要です。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.
理論的には、バイナリパケット全体の暗号化は、安全なシェルデータフローが特徴のないオクテットストリームになることを意味すると主張することができます。しかし、実際には、安全なシェルデータフローはバーストになり、各バーストの長さは基礎となるバイナリパケットの長さと強く相関しています。パケットの長さの暗号化は、それ自体がほとんどなく、基礎となるバイナリパケットの長さを偽装します。Secure Shellは、ランダムパディングとSSH_MSG_IGNOREメッセージの2つの他のメカニズムを提供します。これらは、バイナリパケットの長さによって明らかにされる可能性のある基礎となるプレーンテキストストリームの構造をマスキングする際にパケットの長さを暗号化するよりもはるかに効果的です。
IANA added the following two entries to the secure shell Encryption Algorithm Names registry described in [RFC4250]:
IANAは、[RFC4250]で説明されているSecure Shell暗号化アルゴリズム名レジストリに次の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]で説明されているSecure Shell 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.
[GCM] DWorkin、M、「操作のブロックモードの推奨：Galois/Counter Mode（GCM）およびGMAC」、NIST Special Publication 800-30D、2007年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250] Lehtinen、S。および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月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェイスとアルゴリズム」、RFC 5116、2008年1月。
Authors' Addresses
著者のアドレス
Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency USA
Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency USA
EMail: kmigoe@nsa.gov
Jerome A. Solinas National Information Assurance Research Laboratory National Security Agency USA
ジェロームA.ソリナ国家情報保証研究研究所国家安全保障局USA
EMail: jasolin@orion.ncsc.mil