Network Working Group K. Igoe
Request for Comments: 5647 J. Solinas
Category: Informational National Security Agency
August 2009
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.
版权所有（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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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计数器模式（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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提供机密性和数据完整性通常比使用两个单独的算法提供这些安全服务更有效。
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）特别出版物SP 800 38D[GCM]对伽罗瓦计数器模式给出了极好的解释。在本文档中，我们将重点介绍AES GCM，即在Galois计数器模式下使用高级加密算法（AES）。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
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
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节介绍了如何在secure shell中实现这一目标。
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
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
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的任何系统的安全分析，但这造成了与secure shell要求的不兼容性，我们将在第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.
secure shell的目标是在客户端和服务器之间建立两个安全隧道，一个隧道承载客户端到服务器的通信，另一个承载服务器到客户端的通信。每个隧道都经过加密，并使用消息身份验证代码来确保数据完整性。
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的初始值被保存以用作会话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算法，则还必须选择AES-GCM作为加密算法。
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
如[RFC4253]第7.2节所述，将基于散列的密钥派生函数（KDF）应用于共享密钥值K，以生成所需的对称密钥。每个隧道都有一组不同的
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.
对称密钥。生成的键如图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)
4.会话（id）服务器到客户端哈希（K | H |会话（U）id）服务器到客户端哈希（K | H | H 124|124| H | H | H | H | H 124| H 124124;会话（id）会话（id）id）服务器到服务器到客户端哈希（D）服务器到服务器到客户端哈希（D）哈希（C）服务器到服务器到服务器到客户端哈希（B）哈希（K（K（K 124124124124124124124124124124124\124;| H H H H H H）H H H 124\124124124124124;124||124;124;124; H | | |“F”| | | session| u 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个八位字节的加密密钥。由于AEAD算法（如AES-GCM）使用加密密钥来提供机密性和数据完整性，因此完整性密钥不与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.
服务器或客户端可随时请求对安全shell会话重新设置密钥。共享秘密值K、交换散列H和所有上述对称密钥都将被更新。只有会话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
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:
[RFC5116]第5.1节规定了AEAD_AES_128_GCM。由于安全外壳二进制数据包的格式，实现AEAD_AES_128_GCM所需的缓冲区大小小于[RFC5116]中要求的大小。使用[RFC5116]中定义的符号，secure shell中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_最大明文长度2^32-32个八位字节A_最大额外4个八位字节认证数据长度N_最小非同步（IV）长度12个八位字节N_最大非同步（IV）长度12个八位字节C_最大密码长度2^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:
[RFC5116]第5.2节规定了AEAD_AES_256_GCM。由于安全外壳二进制数据包的格式，实现AEAD_AES_256_GCM所需的缓冲区大小小于[RFC5116]中要求的大小。使用[RFC5116]中定义的符号，secure shell中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_最大明文长度2^32-32个八位字节A_最大额外4个八位字节身份验证数据长度N_最小非同步（IV）长度12个八位字节N_最大非同步（IV）长度12个八位字节C_最大密码长度2^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 secure shell的所有实现都必须使用完整的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个八位组IV被分为两个字段：一个4个八位组的固定字段和一个8个八位组的调用计数器字段。调用字段被视为64位整数，并在每次调用AES-GCM后递增，以处理二进制数据包。
uint32 fixed; // 4 octets
uint64 invocation_counter; // 8 octets
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
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_计数器最初设置为一（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 secure shell中，验证加密的输入为：
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（纯文本）字节填充长度；//4<=填充长度<256字节[n1]有效负载；//n1=数据包长度-填充长度-1字节[n2]随机填充；//n2=填充长度AAD（附加认证数据）uint32数据包长度；//0<=数据包长度<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]的要求，随机_填充长度必须至少为4个八位字节，但不超过255个八位字节。PT的总长度必须是16个八位字节的倍数（AES的块大小）。二进制数据包是4个八位字节的数据包长度、密码文本（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.
2) 在对数据包长度进行解密之前，无法解析数据包。
3) The packet_length cannot be decrypted until the tag has been verified.
3) 在验证标记之前，无法解密数据包的长度。
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与secure shell一起使用时，数据包长度字段将被视为附加的经过身份验证的数据，而不是明文。这违反了[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的形成涉及数据包序列_编号，这是一个32位的值，用于统计在给定SSH隧道上发送的二进制数据包的数量。由于序列号最多为加法常量，仅为调用号计数器的低32位，IV中调用号计数器字段的存在确保序列号确实参与完整性标签的形成，尽管这种参与与[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
如第7.3节所述，GCM要求在验证认证标签之前不返回明文，secure shell要求加密数据包长度，以及解密数据包长度字段以定位认证标签的必要性之间存在不兼容。本文件
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.
通过要求在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.
从理论上讲，有人可能会认为，对整个二进制数据包进行加密意味着安全外壳数据流将变成一个无特征的八位字节流。但实际上，安全shell数据流将以突发的形式出现，每个突发的长度与底层二进制数据包的长度密切相关。数据包长度的加密本身几乎不能掩盖底层二进制数据包的长度。Secure shell提供了另外两种机制，即随机填充和SSH_MSG_IGNORE消息，在屏蔽底层明文流中可能由二进制数据包长度显示的任何结构方面，它们比加密数据包长度要有效得多。
IANA added the following two entries to the secure shell Encryption Algorithm Names registry described in [RFC4250]:
IANA在[RFC4250]中描述的secure shell Encryption Algorithm Names注册表中添加了以下两个条目：
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.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算法名称注册表中添加了以下两个条目：
+--------------------+-------------+
| | |
| Name | Reference |
+--------------------+-------------+
| AEAD_AES_128_GCM | Section 6.1 |
| | |
| AEAD_AES_256_GCM | Section 6.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/计数器模式（GCM）和GMAC”，NIST特别出版物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.，“安全外壳（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]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商业解决方案中心美国国家安全局
EMail: kmigoe@nsa.gov
EMail: kmigoe@nsa.gov
Jerome A. Solinas National Information Assurance Research Laboratory National Security Agency USA
美国国家安全局Jerome A.Solinas国家信息保障研究实验室
EMail: jasolin@orion.ncsc.mil
EMail: jasolin@orion.ncsc.mil