Network Working Group D. Stebila
Request for Comments: 5656 Queensland University of Technology
Category: Standards Track J. Green
Queen's University
December 2009
Network Working Group D. Stebila
Request for Comments: 5656 Queensland University of Technology
Category: Standards Track J. Green
Queen's University
December 2009
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
椭圆曲线算法在安全壳传输层中的集成
Abstract
摘要
This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol.
本文档描述基于椭圆曲线加密（ECC）的算法，用于安全外壳（SSH）传输协议。特别是，它指定了用于SSH传输层协议的椭圆曲线Diffie-Hellman（ECDH）密钥协议、椭圆曲线Menezes-Qu-Vanstone（ECMQV）密钥协议和椭圆曲线数字签名算法（ECDSA）。
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) 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未获得控制此类材料版权的人员的充分许可，不得修改本文件
outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外，不得在IETF标准过程之外创建其衍生作品，除非将其格式化为RFC出版或将其翻译为英语以外的语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Notation ........................................................4
3. SSH ECC Public Key Algorithm ....................................4
3.1. Key Format .................................................4
3.1.1. Signature Algorithm .................................5
3.1.2. Signature Encoding ..................................5
4. ECDH Key Exchange ...............................................5
5. ECMQV Key Exchange ..............................................8
6. Method Names ...................................................10
6.1. Elliptic Curve Domain Parameter Identifiers ...............10
6.2. ECC Public Key Algorithm (ecdsa-sha2-*) ...................11
6.2.1. Elliptic Curve Digital Signature Algorithm .........11
6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) ..............12
6.4. ECMQV Key Exchange and Verification Method Name
(ecmqv-sha2) ..............................................12
7. Key Exchange Messages ..........................................13
7.1. ECDH Message Numbers ......................................13
7.2. ECMQV Message Numbers .....................................13
8. Manageability Considerations ...................................13
8.1. Control of Function through Configuration and Policy ......13
8.2. Impact on Network Operation ...............................14
9. Security Considerations ........................................14
10. Named Elliptic Curve Domain Parameters ........................16
10.1. Required Curves ..........................................16
10.2. Recommended Curves .......................................17
11. IANA Considerations ...........................................17
12. References ....................................................18
12.1. Normative References .....................................18
12.2. Informative References ...................................19
Appendix A. Acknowledgements .....................................20
1. Introduction ....................................................3
2. Notation ........................................................4
3. SSH ECC Public Key Algorithm ....................................4
3.1. Key Format .................................................4
3.1.1. Signature Algorithm .................................5
3.1.2. Signature Encoding ..................................5
4. ECDH Key Exchange ...............................................5
5. ECMQV Key Exchange ..............................................8
6. Method Names ...................................................10
6.1. Elliptic Curve Domain Parameter Identifiers ...............10
6.2. ECC Public Key Algorithm (ecdsa-sha2-*) ...................11
6.2.1. Elliptic Curve Digital Signature Algorithm .........11
6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) ..............12
6.4. ECMQV Key Exchange and Verification Method Name
(ecmqv-sha2) ..............................................12
7. Key Exchange Messages ..........................................13
7.1. ECDH Message Numbers ......................................13
7.2. ECMQV Message Numbers .....................................13
8. Manageability Considerations ...................................13
8.1. Control of Function through Configuration and Policy ......13
8.2. Impact on Network Operation ...............................14
9. Security Considerations ........................................14
10. Named Elliptic Curve Domain Parameters ........................16
10.1. Required Curves ..........................................16
10.2. Recommended Curves .......................................17
11. IANA Considerations ...........................................17
12. References ....................................................18
12.1. Normative References .....................................18
12.2. Informative References ...................................19
Appendix A. Acknowledgements .....................................20
This document adds the following elliptic curve cryptography algorithms to the Secure Shell arsenal: Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), as well as utilizing the SHA2 family of secure hash algorithms. Additionally, support is provided for Elliptic Curve Menezes-Qu-Vanstone (ECMQV).
本文档将以下椭圆曲线密码算法添加到安全外壳库中：椭圆曲线Diffie-Hellman（ECDH）和椭圆曲线数字签名算法（ECDSA），以及利用SHA2系列安全哈希算法。此外，还为椭圆曲线Menezes Qu Vanstone（ECMQV）提供了支持。
Due to its small key sizes and its inclusion in the National Security Agency's Suite B, Elliptic Curve Cryptography (ECC) is becoming a widely utilized and attractive public-key cryptosystem.
由于椭圆曲线密码体制（ECC）的密钥较小，且包含在国家安全局的套件B中，因此它正成为一种广泛使用且极具吸引力的公钥密码体制。
Compared to cryptosystems such as RSA, the Digital Signature Algorithm (DSA), and Diffie-Hellman (DH) key exchange, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [NIST-800-57], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. L is the field size and N is the sub-field size.
与RSA、数字签名算法（DSA）和Diffie-Hellman（DH）密钥交换等密码系统相比，这些方案的ECC变体以较小的密钥大小提供了同等的安全性。下表根据NIST 800-57[NIST-800-57]第5.6.1节说明了这一点，该节根据攻击对称和非对称密钥密码系统的最著名算法给出了近似的可比密钥大小。L是字段大小，N是子字段大小。
+-----------+------------------------------+-------+---------+
| Symmetric | Discrete Log (e.g., DSA, DH) | RSA | ECC |
+-----------+------------------------------+-------+---------+
| 80 | L = 1024, N = 160 | 1024 | 160-223 |
| | | | |
| 112 | L = 2048, N = 256 | 2048 | 224-255 |
| | | | |
| 128 | L = 3072, N = 256 | 3072 | 256-383 |
| | | | |
| 192 | L = 7680, N = 384 | 7680 | 384-511 |
| | | | |
| 256 | L = 15360, N = 512 | 15360 | 512+ |
+-----------+------------------------------+-------+---------+
+-----------+------------------------------+-------+---------+
| Symmetric | Discrete Log (e.g., DSA, DH) | RSA | ECC |
+-----------+------------------------------+-------+---------+
| 80 | L = 1024, N = 160 | 1024 | 160-223 |
| | | | |
| 112 | L = 2048, N = 256 | 2048 | 224-255 |
| | | | |
| 128 | L = 3072, N = 256 | 3072 | 256-383 |
| | | | |
| 192 | L = 7680, N = 384 | 7680 | 384-511 |
| | | | |
| 256 | L = 15360, N = 512 | 15360 | 512+ |
+-----------+------------------------------+-------+---------+
Implementation of this specification requires familiarity with both SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] (additional information on ECC available in [HMV04], [ANSI-X9.62], and [ANSI-X9.63]).
本规范的实施要求熟悉SSH[RFC4251][RFC4253][RFC4250]和ECC[SEC1]（有关ECC的更多信息，请参见[HMV04]、[ANSI-X9.62]和[ANSI-X9.63]）。
This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms is left to other standards documents.
本文档涉及SSH实现细节；底层加密算法的规范留给其他标准文档。
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]中所述进行解释。
The data types boolean, byte, uint32, uint64, string, and mpint are to be interpreted in this document as described in [RFC4251].
布尔、字节、uint32、uint64、字符串和mpint等数据类型将在本文件中按照[RFC4251]中的说明进行解释。
The size of a set of elliptic curve domain parameters on a prime curve is defined as the number of bits in the binary representation of the field order, commonly denoted by p. Size on a characteristic-2 curve is defined as the number of bits in the binary representation of the field, commonly denoted by m. A set of elliptic curve domain parameters defines a group of order n generated by a base point P.
素数曲线上一组椭圆曲线域参数的大小定义为字段顺序二进制表示中的位数，通常用p表示。特征-2曲线上的大小定义为字段二进制表示中的位数，通常用m表示。一组椭圆曲线域参数定义了一组由基点P生成的n阶。
The SSH ECC public key algorithm is defined by its key format, corresponding signature algorithm ECDSA, signature encoding, and algorithm identifiers.
SSH ECC公钥算法由其密钥格式、相应的签名算法ECDSA、签名编码和算法标识符定义。
This section defines the family of "ecdsa-sha2-*" public key formats and corresponding signature formats. Every compliant SSH ECC implementation MUST implement this public key format.
本节定义了“ecdsa-sha2-*”公钥格式系列和相应的签名格式。每个符合要求的SSH ECC实现都必须实现此公钥格式。
The "ecdsa-sha2-*" key formats all have the following encoding:
“ecdsa-sha2-*”密钥格式都具有以下编码：
string "ecdsa-sha2-[identifier]" byte[n] ecc_key_blob
字符串“ecdsa-sha2-[identifier]”字节[n]ecc\U key\U blob
The ecc_key_blob value has the following specific encoding:
ecc_key_blob值具有以下特定编码：
string [identifier] string Q
字符串[标识符]字符串Q
The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1. Information on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm can be found in Section 10.
字符串[identifier]是椭圆曲线域参数的标识符。第6.1节规定了该字符串的格式。在第10节中可以找到与此算法一起使用的所需和推荐的椭圆曲线域参数集的信息。
Q is the public key encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of [SEC1]; point compression MAY be used.
Q是从椭圆曲线点编码为[SEC1]第2.3.3节中定义的八位字节字符串的公钥；可以使用点压缩。
The algorithm for ECC key generation can be found in Section 3.2 of [SEC1]. Given some elliptic curve domain parameters, an ECC key pair can be generated containing a private key (an integer d), and a public key (an elliptic curve point Q).
ECC密钥生成算法见[SEC1]第3.2节。给定一些椭圆曲线域参数，可以生成包含私钥（整数d）和公钥（椭圆曲线点Q）的ECC密钥对。
Signing and verifying is done using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA is specified in [SEC1]. The message hashing algorithm MUST be from the SHA2 family of hash functions [FIPS-180-3] and is chosen according to the curve size as specified in Section 6.2.1.
签名和验证使用椭圆曲线数字签名算法（ECDSA）完成。ECDSA在[SEC1]中指定。消息哈希算法必须来自SHA2系列哈希函数[FIPS-180-3]，并根据第6.2.1节中规定的曲线大小进行选择。
Signatures are encoded as follows:
签名编码如下：
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
字符串“ecdsa-sha2-[identifier]”字符串ecdsa\u签名\u blob
The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1. Information on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm can be found in Section 10.
字符串[identifier]是椭圆曲线域参数的标识符。第6.1节规定了该字符串的格式。在第10节中可以找到与此算法一起使用的所需和推荐的椭圆曲线域参数集的信息。
The ecdsa_signature_blob value has the following specific encoding:
ecdsa_signature_blob值具有以下特定编码：
mpint r mpint s
mpint r mpint s
The integers r and s are the output of the ECDSA algorithm.
整数r和s是ECDSA算法的输出。
The width of the integer fields is determined by the curve being used. Note that the integers r and s are integers modulo the order of the cryptographic subgroup, which may be larger than the size of the finite field.
整数字段的宽度由所使用的曲线决定。注意，整数r和s是密码子组阶数模的整数，其可能大于有限域的大小。
The Elliptic Curve Diffie-Hellman (ECDH) key exchange method generates a shared secret from an ephemeral local elliptic curve private key and ephemeral remote elliptic curve public key. This key exchange method provides explicit server authentication as defined in [RFC4253] using a signature on the exchange hash. Every compliant SSH ECC implementation MUST implement ECDH key exchange.
椭圆曲线Diffie-Hellman（ECDH）密钥交换方法从临时本地椭圆曲线私钥和临时远程椭圆曲线公钥生成共享密钥。此密钥交换方法使用交换哈希上的签名提供[RFC4253]中定义的显式服务器身份验证。每个符合要求的SSH ECC实现都必须实现ECDH密钥交换。
The primitive used for shared key generation is ECDH with cofactor multiplication, the full specification of which can be found in Section 3.3.2 of [SEC1]. The algorithm for key pair generation can be found in Section 3.2.1 of [SEC1].
用于共享密钥生成的原语是带有辅因子乘法的ECDH，其完整规范见[SEC1]第3.3.2节。密钥对生成算法见[SEC1]第3.2.1节。
The family of key exchange method names defined for use with this key exchange can be found in Section 6.3. Algorithm negotiation chooses the public key algorithm to be used for signing and the method name of the key exchange. The method name of the key exchange chosen determines the elliptic curve domain parameters and hash function to be used in the remainder of this section.
在第6.3节中可以找到定义用于此密钥交换的密钥交换方法名称系列。算法协商选择用于签名的公钥算法和密钥交换的方法名称。所选密钥交换的方法名决定了本节剩余部分中要使用的椭圆曲线域参数和哈希函数。
Information on the REQUIRED and RECOMMENDED elliptic curve domain parameters for use with this method can be found in Section 10.
关于此方法所需和推荐的椭圆曲线域参数的信息，请参见第10节。
All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail.
所有椭圆曲线公钥必须在收到后进行验证。验证算法示例见[SEC1]第3.2.2节。如果密钥验证失败，则密钥交换必须失败。
The elliptic curve public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of [SEC1].
必须传输的椭圆曲线公钥（点）在传输前被编码成八位字符串。[SEC1]第2.3.3节和第2.3.4节规定了椭圆曲线点和八位字符串之间的转换；可以使用点压缩。共享密钥生成的输出是字段元素xp。SSH框架要求共享密钥为整数。[SEC1]第2.3.9节规定了字段元素和整数之间的转换。
Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY is found in Section 7.
第7节给出了消息编号SSH_MSG_KEX_ECDH_INIT和SSH_MSG_KEX_ECDH_REPLY的说明。
The following is an overview of the key exchange process:
以下是密钥交换过程的概述：
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECDH_INIT -------------->
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECDH_INIT -------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
<------------- SSH_MSG_KEX_ECDH_REPLY
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
<------------- SSH_MSG_KEX_ECDH_REPLY
Verify received key is valid. *Verify host key belongs to server. Compute shared secret. Generate exchange hash. Verify server's signature.
验证收到的密钥是否有效*验证主机密钥属于服务器。计算共享秘密。生成交换哈希。验证服务器的签名。
* It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks; see the discussion in Section 4.1 of [RFC4251].
* 建议客户端验证发送的主机密钥是否为服务器的主机密钥（例如，使用本地数据库）。客户端可以接受主机密钥而无需验证，但这样做会使协议不安全，无法抵御主动攻击；参见[RFC4251]第4.1节中的讨论。
This is implemented using the following messages.
这是使用以下消息实现的。
The client sends:
客户端发送：
byte SSH_MSG_KEX_ECDH_INIT string Q_C, client's ephemeral public key octet string
字节SSH_MSG_KEX_ECDH_INIT string Q_C，客户端的临时公钥八位字符串
The server responds with:
服务器响应为：
byte SSH_MSG_KEX_ECDH_REPLY string K_S, server's public host key string Q_S, server's ephemeral public key octet string string the signature on the exchange hash
字节SSH_MSG_KEX_ECDH_回复字符串K_S、服务器的公钥字符串Q_S、服务器的临时公钥八位字符串字符串exchange哈希上的签名
The exchange hash H is computed as the hash of the concatenation of the following.
交换散列H被计算为下列连接的散列。
string V_C, client's identification string (CR and LF excluded) string V_S, server's identification string (CR and LF excluded) string I_C, payload of the client's SSH_MSG_KEXINIT string I_S, payload of the server's SSH_MSG_KEXINIT string K_S, server's public host key string Q_C, client's ephemeral public key octet string string Q_S, server's ephemeral public key octet string mpint K, shared secret
字符串V_C，客户端的标识字符串（CR和LF除外）字符串V_s，服务器的标识字符串（CR和LF除外）字符串I_C，客户端的SSH_MSG_KEXINIT字符串I_s的有效负载，服务器的SSH_MSG_KEXINIT字符串K_s的有效负载，服务器的公共主机密钥字符串Q_C，客户端的临时公钥八位组字符串Q_s，服务器的临时公钥八位字节字符串mpint K，共享密钥
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm generates a shared secret from two local elliptic curve key pairs and two remote public keys. This key exchange method provides implicit server authentication as defined in [RFC4253]. The ECMQV key exchange method is OPTIONAL.
椭圆曲线Menezes-Qu-Vanstone（ECMQV）密钥交换算法从两个本地椭圆曲线密钥对和两个远程公钥生成共享密钥。此密钥交换方法提供[RFC4253]中定义的隐式服务器身份验证。ECMQV密钥交换方法是可选的。
The key exchange method name defined for use with this key exchange is "ecmqv-sha2". This method name gives a hashing algorithm that is to be used for the Hashed Message Authentication Code (HMAC) below. Future RFCs may define new method names specifying new hash algorithms for use with ECMQV. More information about the method name and HMAC can be found in Section 6.4.
定义用于此密钥交换的密钥交换方法名称为“ecmqv-sha2”。此方法名称提供了一个哈希算法，用于下面的哈希消息身份验证代码（HMAC）。未来的RFC可能会定义新的方法名，指定新的哈希算法以用于ECMQV。有关方法名称和HMAC的更多信息，请参见第6.4节。
In general, the ECMQV key exchange is performed using the ephemeral and long-term key pair of both the client and server, which is a total of 4 keys. Within the framework of SSH, the client does not have a long-term key pair that needs to be authenticated. Therefore, we generate an ephemeral key and use that as both the clients keys. This is more efficient than using two different ephemeral keys, and it does not adversely affect security (it is analogous to the one-pass protocol in Section 6.1 of [LMQSV98]).
通常，ECMQV密钥交换是使用客户机和服务器的临时和长期密钥对执行的，共有4个密钥。在SSH框架内，客户端没有需要验证的长期密钥对。因此，我们生成一个临时密钥并将其用作两个客户端密钥。这比使用两个不同的临时密钥更有效，并且不会对安全性产生不利影响（类似于[LMQSV98]第6.1节中的单通协议）。
A full description of the ECMQV primitive can be found in Section 3.4 of [SEC1]. The algorithm for key pair generation can be found in Section 3.2.1 of [SEC1].
ECMQV原语的完整描述见[SEC1]的第3.4节。密钥对生成算法见[SEC1]第3.2.1节。
During algorithm negotiation with the SSH_MSG_KEXINIT messages, the ECMQV key exchange method can only be chosen if a public key algorithm supporting ECC host keys can also be chosen. This is due to the use of implicit server authentication in this key exchange method. This case is handled the same way that key exchange methods requiring encryption/signature capable public key algorithms are
在与SSH_MSG_KEXINIT消息进行算法协商期间，只有在还可以选择支持ECC主机密钥的公钥算法的情况下，才能选择ECMQV密钥交换方法。这是因为在此密钥交换方法中使用了隐式服务器身份验证。这种情况的处理方式与需要支持加密/签名的公钥算法的密钥交换方法相同
handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen, then the public key algorithm supporting ECC host keys MUST also be chosen.
在[RFC4253]第7.1节中处理。如果选择了ECMQV密钥交换，则还必须选择支持ECC主机密钥的公钥算法。
ECMQV requires that all the keys used to generate a shared secret are generated over the same elliptic curve domain parameters. Since the host key is used in the generation of the shared secret, allowing for implicit server authentication, the domain parameters associated with the host key are used throughout this section.
ECMQV要求用于生成共享密钥的所有密钥都是在相同的椭圆曲线域参数上生成的。由于主机密钥用于生成共享密钥，从而允许隐式服务器身份验证，因此与主机密钥相关联的域参数将在本节中使用。
All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail.
所有椭圆曲线公钥必须在收到后进行验证。验证算法示例见[SEC1]第3.2.2节。如果密钥验证失败，则密钥交换必须失败。
The elliptic curve ephemeral public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of [SEC1].
必须传输的椭圆曲线临时公钥（点）在传输前编码为八位字节字符串。[SEC1]第2.3.3节和第2.3.4节规定了椭圆曲线点和八位字符串之间的转换；可以使用点压缩。共享密钥生成的输出是字段元素xp。SSH框架要求共享密钥为整数。[SEC1]第2.3.9节规定了字段元素和整数之间的转换。
The following is an overview of the key exchange process:
以下是密钥交换过程的概述：
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECMQV_INIT ------------->
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECMQV_INIT ------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate exchange hash and compute
HMAC over it using the shared secret.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate exchange hash and compute
HMAC over it using the shared secret.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Verify received keys are valid. *Verify host key belongs to server. Compute shared secret. Verify HMAC.
验证收到的密钥是否有效*验证主机密钥属于服务器。计算共享秘密。验证HMAC。
* It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks.
* 建议客户端验证发送的主机密钥是否为服务器的主机密钥（例如，使用本地数据库）。客户端可以在未经验证的情况下接受主机密钥，但这样做会使协议不安全，无法抵御主动攻击。
The specification of the message numbers SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7.
第7节中可以找到消息编号SSH_MSG_ECMQV_INIT和SSH_MSG_ECMQV_REPLY的规范。
This key exchange algorithm is implemented with the following messages.
此密钥交换算法由以下消息实现。
The client sends:
客户端发送：
byte SSH_MSG_ECMQV_INIT string Q_C, client's ephemeral public key octet string
字节SSH_MSG_ECMQV_INIT string Q_C，客户端的临时公钥八位字节字符串
The server sends:
服务器发送：
byte SSH_MSG_ECMQV_REPLY string K_S, server's public host key string Q_S, server's ephemeral public key octet string string HMAC tag computed on H using the shared secret
字节SSH_MSG_ECMQV_回复字符串K_S，服务器的公共主机密钥字符串Q_S，服务器的临时公钥八位组字符串HMAC标记，使用共享密钥在H上计算
The hash H is formed by applying the algorithm HASH on a concatenation of the following:
散列H是通过将算法散列应用于以下内容的串联而形成的：
string V_C, client's identification string (CR and LF excluded) string V_S, server's identification string (CR and LF excluded) string I_C, payload of the client's SSH_MSG_KEXINIT string I_S, payload of the server's SSH_MSG_KEXINIT string K_S, server's public host key string Q_C, client's ephemeral public key octet string string Q_S, server's ephemeral public key octet string mpint K, shared secret
字符串V_C，客户端的标识字符串（CR和LF除外）字符串V_s，服务器的标识字符串（CR和LF除外）字符串I_C，客户端的SSH_MSG_KEXINIT字符串I_s的有效负载，服务器的SSH_MSG_KEXINIT字符串K_s的有效负载，服务器的公共主机密钥字符串Q_C，客户端的临时公钥八位组字符串Q_s，服务器的临时公钥八位字节字符串mpint K，共享密钥
This document defines a new family of key exchange method names, a new key exchange method name, and a new family of public key algorithm names in the SSH name registry.
本文档在SSH名称注册表中定义了一系列新的密钥交换方法名称、一系列新的密钥交换方法名称和一系列新的公钥算法名称。
This section specifies identifiers encoding named elliptic curve domain parameters. These identifiers are used in this document to identify the curve used in the SSH ECC public key format, the ECDSA signature blob, and the ECDH method name.
本节指定编码命名为椭圆曲线域参数的标识符。本文档中使用这些标识符来标识SSH ECC公钥格式中使用的曲线、ECDSA签名blob和ECDH方法名称。
For the REQUIRED elliptic curves nistp256, nistp384, and nistp521, the elliptic curve domain parameter identifiers are the strings "nistp256", "nistp384", and "nistp521".
对于所需的椭圆曲线nistp256、nistp384和nistp521，椭圆曲线域参数标识符是字符串“nistp256”、“nistp384”和“nistp521”。
For all other elliptic curves, including all other NIST curves and all other RECOMMENDED curves, the elliptic curve domain parameter identifier is the ASCII period-separated decimal representation of the Abstract Syntax Notation One (ASN.1) [ASN1] Object Identifier (OID) of the named curve domain parameters that are associated with the server's ECC host keys. This identifier is defined provided that the concatenation of the public key format identifier and the elliptic curve domain parameter identifier (or the method name and the elliptic curve domain parameter identifier) does not exceed the maximum specified by the SSH protocol architecture [RFC4251], namely 64 characters; otherwise, the identifier for that curve is undefined, and the curve is not supported by this specification.
对于所有其他椭圆曲线，包括所有其他NIST曲线和所有其他推荐曲线，椭圆曲线域参数标识符是抽象语法符号1（ASN.1）[ASN1]对象标识符（OID）的ASCII句点分隔十进制表示形式与服务器的ECC主机密钥关联的命名曲线域参数的。如果公钥格式标识符和椭圆曲线域参数标识符（或方法名称和椭圆曲线域参数标识符）的串联不超过SSH协议体系结构[RFC4251]指定的最大值，即64个字符，则定义该标识符；否则，该曲线的标识符未定义，并且该规范不支持该曲线。
A list of the REQUIRED and RECOMMENDED curves and their OIDs can be found in Section 10.
第10节中列出了要求的和推荐的曲线及其OID。
Note that implementations MUST use the string identifiers for the three REQUIRED NIST curves, even when an OID exists for that curve.
请注意，实现必须为三条必需的NIST曲线使用字符串标识符，即使该曲线存在OID。
The SSH ECC public key algorithm is specified by a family of public key format identifiers. Each identifier is the concatenation of the string "ecdsa-sha2-" with the elliptic curve domain parameter identifier as defined in Section 6.1. A list of the required and recommended curves and their OIDs can be found in Section 10.
SSH ECC公钥算法由一系列公钥格式标识符指定。每个标识符是字符串“ecdsa-sha2-”与第6.1节中定义的椭圆曲线域参数标识符的串联。第10节中列出了要求的和推荐的曲线及其OID。
For example, the method name for ECDH key exchange with ephemeral keys generated on the nistp256 curve is "ecdsa-sha2-nistp256".
例如，使用nistp256曲线上生成的临时密钥进行ECDH密钥交换的方法名称为“ecdsa-sha2-nistp256”。
The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified for use with the SSH ECC public key algorithm.
椭圆曲线数字签名算法（ECDSA）指定与SSH ECC公钥算法一起使用。
The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the public key:
该方法名族定义的哈希算法是SHA2哈希算法族[FIPS-180-3]。根据公钥中指定的命名曲线的大小选择将使用的SHA2族算法：
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
The Elliptic Curve Diffie-Hellman (ECDH) key exchange is defined by a family of method names. Each method name is the concatenation of the string "ecdh-sha2-" with the elliptic curve domain parameter identifier as defined in Section 6.1. A list of the required and recommended curves and their OIDs can be found in Section 10.
椭圆曲线Diffie-Hellman（ECDH）密钥交换由一系列方法名定义。每个方法名称都是字符串“ecdh-sha2-”与第6.1节中定义的椭圆曲线域参数标识符的串联。第10节中列出了要求的和推荐的曲线及其OID。
For example, the method name for ECDH key exchange with ephemeral keys generated on the sect409k1 curve is "ecdh-sha2-1.3.132.0.36".
例如，与sect409k1曲线上生成的临时密钥进行ECDH密钥交换的方法名称为“ECDH-sha2-1.3.132.0.36”。
The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms [FIPS-180-3]. The hashing algorithm is defined in the method name to allow room for other algorithms to be defined in future documents. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the method name according to the table in Section 6.2.1.
该方法名族定义的哈希算法是SHA2哈希算法族[FIPS-180-3]。散列算法在方法名称中定义，以便在将来的文档中为其他算法定义空间。根据第6.2.1节中的表格，根据方法名称中指定的命名曲线的大小，选择将使用的SHA2系列算法。
The concatenation of any so encoded ASN.1 OID specifying a set of elliptic curve domain parameters with "ecdh-sha2-" is implicitly registered under this specification.
任何如此编码的ASN.1 OID（指定一组椭圆曲线域参数）与“ecdh-sha2-”的串联都隐式注册在本规范下。
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange is defined by the method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV relies on a public key algorithm that uses ECC keys: it does not need a family of method names because the curve information can be gained from the public key algorithm.
椭圆曲线Menezes Qu Vanstone（ECMQV）密钥交换由方法名“ECMQV-sha2”定义。与ECDH密钥交换方法不同，ECMQV依赖于使用ECC密钥的公钥算法：它不需要一系列方法名称，因为曲线信息可以从公钥算法中获得。
The hashing and message authentication code algorithms are defined by the method name to allow room for other algorithms to be defined for use with ECMQV in future documents.
散列和消息身份验证代码算法由方法名称定义，以便为其他算法定义空间，以便在将来的文档中与ECMQV一起使用。
The hashing algorithm defined by this method name is the SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified for use with ECMQV by the chosen public key algorithm according to the table in Section 6.2.1.
此方法名称定义的哈希算法是SHA2哈希算法家族[FIPS-180-3]。根据第6.2.1节中的表，根据所选公钥算法指定用于ECMQV的命名曲线的大小，选择将使用的SHA2系列算法。
The keyed-hash message authentication code that is used to identify the server and verify communications is based on the hash chosen above. The information on implementing the HMAC based on the chosen hash algorithm can be found in [RFC2104].
用于标识服务器和验证通信的密钥散列消息身份验证代码基于上面选择的散列。有关基于所选哈希算法实现HMAC的信息，请参见[RFC2104]。
The message numbers 30-49 are key-exchange-specific and in a private namespace defined in [RFC4250] that may be redefined by any key exchange method [RFC4253] without requiring an IANA registration process.
消息编号30-49是密钥交换专用的，位于[RFC4250]中定义的私有名称空间中，该名称空间可以由任何密钥交换方法[RFC4253]重新定义，而无需IANA注册过程。
The following message numbers have been defined in this document:
本文件中定义了以下消息编号：
#define SSH_MSG_KEX_ECDH_INIT 30 #define SSH_MSG_KEX_ECDH_REPLY 31
#定义SSH_MSG_KEX_ECDH_INIT 30#定义SSH_MSG_KEX_ECDH_回复31
#define SSH_MSG_ECMQV_INIT 30 #define SSH_MSG_ECMQV_REPLY 31
#定义SSH_MSG_ECMQV_INIT 30#定义SSH_MSG_ECMQV_回复31
As this document only provides new public key algorithms and key exchange methods within the existing Secure Shell protocol architecture, there are few manageability considerations beyond those that apply for existing Secure Shell implementations. Additional manageability considerations are listed below.
由于本文档仅提供了现有Secure Shell协议体系结构中的新公钥算法和密钥交换方法，因此除了适用于现有Secure Shell实现的可管理性考虑因素外，几乎没有其他可管理性考虑因素。下面列出了其他可管理性注意事项。
Section 10 specifies REQUIRED and RECOMMENDED elliptic curve domain parameters to be used with the public key algorithms and key exchange methods defined in this document. Implementers SHOULD allow system administrators to disable some curves, including REQUIRED or RECOMMENDED curves, to meet local security policy.
第10节规定了本文件中定义的公钥算法和密钥交换方法所需和推荐的椭圆曲线域参数。实现者应该允许系统管理员禁用某些曲线，包括必需的或推荐的曲线，以满足本地安全策略的要求。
As this document provides new functionality within the Secure Shell protocol architecture, the only impact on network operations is the impact on existing Secure Shell implementations. The Secure Shell protocol provides negotiation mechanisms for public key algorithms and key exchange methods: any implementations that do not recognize the algorithms and methods defined in this document will ignore them in the negotiation and use the next mutually supported algorithm or method, causing no negative impact on backward compatibility.
由于本文档提供了Secure Shell协议体系结构中的新功能，因此对网络操作的唯一影响是对现有Secure Shell实现的影响。Secure Shell协议为公钥算法和密钥交换方法提供协商机制：任何不识别本文档中定义的算法和方法的实现将在协商中忽略它们，并使用下一个相互支持的算法或方法，不会对向后兼容性造成负面影响。
The use of elliptic curve cryptography should not place a significant computational burden on an implementing server. In fact, due to its smaller key sizes, elliptic curve cryptography can be implemented more efficiently for the same security level than RSA, finite field Diffie-Hellman, or DSA.
椭圆曲线密码的使用不应该给实现服务器带来很大的计算负担。事实上，由于椭圆曲线密码具有较小的密钥大小，因此在相同的安全级别下，椭圆曲线密码可以比RSA、有限域Diffie-Hellman或DSA更有效地实现。
This document provides new public key algorithms and new key agreement methods for the Secure Shell protocol. For the most part, the security considerations involved in using the Secure Shell protocol apply. Additionally, implementers should be aware of security considerations specific to elliptic curve cryptography.
本文档为Secure Shell协议提供了新的公钥算法和新的密钥协商方法。在大多数情况下，使用Secure Shell协议所涉及的安全注意事项适用。此外，实现者应该了解椭圆曲线密码术特有的安全注意事项。
For all three classes of functionality added by this document (the public key algorithms involving ECDSA, key exchange involving ECDH, and authenticated key exchange involving ECMQV), the current best known technique for breaking the cryptosystems is by solving the elliptic curve discrete logarithm problem (ECDLP).
对于本文档添加的所有三类功能（涉及ECDSA的公钥算法、涉及ECDH的密钥交换和涉及ECMQV的认证密钥交换），目前最著名的破解密码系统的技术是解决椭圆曲线离散对数问题（ECDLP）。
The difficulty of breaking the ECDLP depends on the size and quality of the elliptic curve parameters. Certain types of curves can be more susceptible to known attacks than others. For example, curves over finite fields GF(2^m), where m is composite, may be susceptible to an attack based on the Weil descent. All of the RECOMMENDED curves in Section 10 do not have this problem. System administrators should be cautious when enabling curves other than the ones specified in Section 10 and should make a more detailed investigation into the security of the curve in question.
打破ECDLP的难度取决于椭圆曲线参数的大小和质量。某些类型的曲线比其他曲线更容易受到已知攻击。例如，有限域GF（2^m）上的曲线，其中m是复合的，可能容易受到基于Weil下降的攻击。第10节中的所有推荐曲线均不存在此问题。系统管理员在启用第10节规定以外的曲线时应谨慎，并应更详细地调查相关曲线的安全性。
It is believed (see, for example, Section B.2.1 of [SEC1]) that when curve parameters are generated at random, the curves will be resistant to special attacks, and must rely on the most general attacks. The REQUIRED curves in Section 10 were all generated verifiably pseudorandomly. The runtime of general attacks depends on the algorithm used. At present, the best known algorithm is the Pollard-rho method. (Shor's algorithm for quantum computers can
人们相信（例如，参见[SEC1]第B.2.1节），当随机生成曲线参数时，曲线将抵抗特殊攻击，并且必须依赖最一般的攻击。第10节中要求的曲线都是可验证的伪随机生成的。一般攻击的运行时间取决于使用的算法。目前，最著名的算法是Pollard-rho方法。（肖尔的量子计算机算法可以
solve the ECDLP in polynomial time, but at present large-scale quantum computers have not been constructed and significant experimental physics and engineering work needs to be done before large-scale quantum computers can be constructed. There is no solid estimate as to when this may occur, but it is widely believed to be at least 20 years from the present.)
在多项式时间内求解ECDLP，但目前尚未构建大规模量子计算机，在构建大规模量子计算机之前，需要进行大量的实验物理和工程工作。关于何时可能发生这种情况，目前还没有可靠的估计，但人们普遍认为至少还有20年的时间。）
Based on projections of computation power, it is possible to estimate the running time of the best known attacks based on the size of the finite field. The table in Section 1 gives an estimate of the equivalence between elliptic curve field size and symmetric key size. Roughly speaking, an N-bit elliptic curve offers the same security as an N/2-bit symmetric cipher, so a 256-bit elliptic curve (such as the REQUIRED nistp256 curve) is suitable for use with 128-bit AES, for example.
基于计算能力的预测，可以根据有限域的大小估计最著名攻击的运行时间。第1节中的表给出了椭圆曲线字段大小和对称密钥大小之间等价性的估计。粗略地说，N位椭圆曲线提供了与N/2位对称密码相同的安全性，因此，例如，256位椭圆曲线（如所需的nistp256曲线）适用于128位AES。
Many estimates consider that 2^80-2^90 operations are beyond feasible, so that would suggest using elliptic curves of at least 160-180 bits. The REQUIRED curves in this document are 256-, 384-, and 521-bit curves; implementations SHOULD NOT use curves smaller than 160 bits.
许多估计认为2 ^ 80-2 ^ 90操作是不可行的，因此建议使用至少160～180位的椭圆曲线。本文件中要求的曲线为256、384和521位曲线；实现不应使用小于160位的曲线。
A detailed discussion on the security considerations of elliptic curve domain parameters and the ECDH, ECDSA, and ECMQV algorithms can be found in Appendix B of [SEC1].
关于椭圆曲线域参数和ECDH、ECDSA和ECMQV算法的安全注意事项的详细讨论见[SEC1]的附录B。
Additionally, the key exchange methods defined in this document rely on the SHA2 family of hash functions, defined in [FIPS-180-3]. The appropriate security considerations of that document apply. Although some weaknesses have been discovered in the predecessor, SHA-1, no weaknesses in the SHA2 family are known at present. The SHA2 family consists of four variants -- SHA-224, SHA-256, SHA-384, and SHA-521 -- named after their digest lengths. In the absence of special purpose attacks exploiting the specific structure of the hash function, the difficulty of finding collisions, preimages, and second preimages for the hash function is related to the digest length. This document specifies in Section 6.2.1 which SHA2 variant should be used with which elliptic curve size based on this guidance.
此外，本文件中定义的密钥交换方法依赖于[FIPS-180-3]中定义的SHA2哈希函数族。该文件的适当安全考虑适用。虽然在先前的SHA-1中发现了一些弱点，但目前尚不清楚SHA-2系列中的弱点。SHA2家族由四个变种组成——SHA-224、SHA-256、SHA-384和SHA-521——以其摘要长度命名。在没有利用哈希函数特定结构的特殊目的攻击的情况下，查找哈希函数的冲突、前映像和第二前映像的难度与摘要长度有关。本文件在第6.2.1节中规定了应根据本指南使用哪种SHA2变体和哪种椭圆曲线尺寸。
Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [NIST-800-57]; the discussion in [RFC3766] is also relevant. We note in particular that when ECDSA is used as the
由于ECDH和ECMQV允许任意大小的椭圆曲线，从而允许任意的安全强度，因此选择椭圆曲线的大小以匹配SSH握手的其他元素的安全强度非常重要。特别是，必须适当选择主机密钥大小、哈希算法和批量加密算法。[NIST-800-57]中提供了有关关键尺寸估计等效性的信息；[RFC3766]中的讨论也是相关的。我们特别注意到，当ECDSA用作
signature algorithm and ECDH is used as the key exchange method, if curves of different sizes are used, then it is possible that different hash functions from the SHA2 family could be used.
签名算法和ECDH用作密钥交换方法，如果使用不同大小的曲线，则可能使用来自SHA2系列的不同哈希函数。
The REQUIRED and RECOMMENDED curves in this document are at present believed to offer security at the levels indicated in this section and as specified with the table in Section 1.
目前认为，本文件中要求的和建议的曲线在本节所示的水平以及第1节表格中规定的水平上提供了安全性。
System administrators and implementers should take careful consideration of the security issues when enabling curves other than the REQUIRED or RECOMMENDED curves in this document. Not all elliptic curves are secure, even if they are over a large field.
系统管理员和实施者在启用本文档中要求或推荐曲线以外的曲线时，应仔细考虑安全问题。并非所有的椭圆曲线都是安全的，即使它们在一个大的域上。
Implementers SHOULD ensure that any ephemeral private keys or random values -- including the value k used in ECDSA signature generation and the ephemeral private key values in ECDH and ECMQV -- are generated from a random number generator or a properly seeded pseudorandom number generator, are protected from leakage, are not reused outside of the context of the protocol in this document, and are erased from memory when no longer needed.
实施者应确保任何临时私钥或随机值（包括ECDSA签名生成中使用的值k以及ECDH和ECMQV中的临时私钥值）都是从随机数生成器或正确播种的伪随机数生成器生成的，以防止泄漏，在本文档的协议上下文之外不会重复使用，并且在不再需要时从内存中删除。
Implementations MAY support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters [ASN1].
实现可能支持ASN.1对象树中定义一组椭圆曲线域参数[ASN1]的任何ASN.1对象标识符（OID）。
Every SSH ECC implementation MUST support the named curves below. These curves are defined in [SEC2]; the NIST curves were originally defined in [NIST-CURVES]. These curves SHOULD always be enabled unless specifically disabled by local security policy.
每个SSH ECC实现都必须支持下面的命名曲线。这些曲线在[SEC2]中定义；NIST曲线最初在[NIST-curves]中定义。除非本地安全策略特别禁用，否则应始终启用这些曲线。
+----------+-----------+---------------------+
| NIST* | SEC | OID |
+----------+-----------+---------------------+
| nistp256 | secp256r1 | 1.2.840.10045.3.1.7 |
| | | |
| nistp384 | secp384r1 | 1.3.132.0.34 |
| | | |
| nistp521 | secp521r1 | 1.3.132.0.35 |
+----------+-----------+---------------------+
+----------+-----------+---------------------+
| NIST* | SEC | OID |
+----------+-----------+---------------------+
| nistp256 | secp256r1 | 1.2.840.10045.3.1.7 |
| | | |
| nistp384 | secp384r1 | 1.3.132.0.34 |
| | | |
| nistp521 | secp521r1 | 1.3.132.0.35 |
+----------+-----------+---------------------+
* For these three REQUIRED curves, the elliptic curve domain parameter identifier is the string in the first column of the table, the NIST name of the curve. (See Section 6.1.)
* 对于这三条必需的曲线，椭圆曲线域参数标识符是表格第一列中的字符串，即曲线的NIST名称。（见第6.1节。）
It is RECOMMENDED that SSH ECC implementations also support the following curves. These curves are defined in [SEC2].
建议SSH ECC实现也支持以下曲线。这些曲线在[SEC2]中定义。
+----------+-----------+---------------------+
| NIST | SEC | OID* |
+----------+-----------+---------------------+
| nistk163 | sect163k1 | 1.3.132.0.1 |
| | | |
| nistp192 | secp192r1 | 1.2.840.10045.3.1.1 |
| | | |
| nistp224 | secp224r1 | 1.3.132.0.33 |
| | | |
| nistk233 | sect233k1 | 1.3.132.0.26 |
| | | |
| nistb233 | sect233r1 | 1.3.132.0.27 |
| | | |
| nistk283 | sect283k1 | 1.3.132.0.16 |
| | | |
| nistk409 | sect409k1 | 1.3.132.0.36 |
| | | |
| nistb409 | sect409r1 | 1.3.132.0.37 |
| | | |
| nistt571 | sect571k1 | 1.3.132.0.38 |
+----------+-----------+---------------------+
+----------+-----------+---------------------+
| NIST | SEC | OID* |
+----------+-----------+---------------------+
| nistk163 | sect163k1 | 1.3.132.0.1 |
| | | |
| nistp192 | secp192r1 | 1.2.840.10045.3.1.1 |
| | | |
| nistp224 | secp224r1 | 1.3.132.0.33 |
| | | |
| nistk233 | sect233k1 | 1.3.132.0.26 |
| | | |
| nistb233 | sect233r1 | 1.3.132.0.27 |
| | | |
| nistk283 | sect283k1 | 1.3.132.0.16 |
| | | |
| nistk409 | sect409k1 | 1.3.132.0.36 |
| | | |
| nistb409 | sect409r1 | 1.3.132.0.37 |
| | | |
| nistt571 | sect571k1 | 1.3.132.0.38 |
+----------+-----------+---------------------+
* For these RECOMMENDED curves, the elliptic curve domain parameter identifier is the string in the third column of the table, the ASCII representation of the OID of the curve. (See Section 6.1.)
* 对于这些推荐曲线，椭圆曲线域参数标识符是表格第三列中的字符串，即曲线OID的ASCII表示形式。（见第6.1节。）
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations:
根据[RFC4251]第8节和[RFC4250]第4.6节，本文件进行了以下登记：
In the Public Key Algorithm Names registry: The family of SSH public key algorithm names beginning with "ecdsa-sha2-" and not containing the at-sign ('@'), to name the public key algorithms defined in Section 3.
在公钥算法名称注册表中：以“ecdsa-sha2-”开头且不包含at符号（“@”）的SSH公钥算法名称系列，用于命名第3节中定义的公钥算法。
In the Key Exchange Method Names registry: The family of SSH key exchange method names beginning with "ecdh-sha2-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 4.
在密钥交换方法名称注册表中：以“ecdh-sha2-”开头且不包含at符号（'@'）的SSH密钥交换方法名称族，用于命名第4节中定义的密钥交换方法。
In the Key Exchange Method Names registry: The SSH key exchange method name "ecmqv-sha2" to name the key exchange method defined in Section 5.
在密钥交换方法名称注册表中：使用SSH密钥交换方法名称“ecmqv-sha2”来命名第5节中定义的密钥交换方法。
This document creates no new registries.
此文档不创建新的注册表。
[ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002.
[ASN1]国际电信联盟，“抽象语法符号一（ASN.1）：基本符号规范”，X.680，2002年7月。
[FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]国家标准与技术研究所，“安全哈希标准”，FIPS 180-32008年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]Lehtinen，S.和C.Lonvick，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "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, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, May 2009, <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC1]高效密码标准组，“椭圆曲线密码术”，第1节，2009年5月<http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000, <http://www.secg.org/download/aid-386/sec2_final.pdf>.
[SEC2]高效密码标准组，“建议的椭圆曲线域参数”，第2节，2000年9月<http://www.secg.org/download/aid-386/sec2_final.pdf>.
[ANSI-X9.62] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998.
[ANSI-X9.62]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.621998。
[ANSI-X9.63] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, January 1999.
[ANSI-X9.63]美国国家标准协会，“金融服务业的公钥加密：使用椭圆曲线加密的密钥协议和密钥传输”，ANSI X9.63，1999年1月。
[HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to Elliptic Curve Cryptography", Springer ISBN 038795273X, 2004.
[HMV04]Hankerson，D.，Menezes，A.，和S.Vanstone，“椭圆曲线密码术指南”，Springer ISBN 038795273X，2004年。
[LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. Vanstone, "An Efficient Protocol for Authenticated Key Agreement", University of Waterloo Technical Report CORR 98-05, August 1998, <http:// www.cacr.math.uwaterloo.ca/techreports/1998/ corr98-05.pdf>.
[LMQV98]法律，L.，MeNeZes，A.，曲，M，Solinas，J.和S. Vanstone，“一个有效的认证密钥协议协议”，滑铁卢大学技术报告CORR 98－05，1998年8月，http://www. cActh.Math.UWATOLU.CA/TeaRePrts/98/CURR985-PDF>
[NIST-800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[NIST-800-57]国家标准与技术研究所，“关键管理建议-第1部分：总则（修订）”，NIST特别出版物800-57，2007年3月。
[NIST-CURVES] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", July 1999.
[NIST-CURVES]国家标准与技术研究所，“联邦政府使用的建议椭圆曲线”，1999年7月。
The authors acknowledge helpful comments from James Blaisdell, David Harrington, Alfred Hoenes, Russ Housley, Jeffrey Hutzelman, Kevin Igoe, Rob Lambert, Jan Pechanek, Tim Polk, Sean Turner, Nicolas Williams, and members of the ietf-ssh@netbsd.org mailing list.
作者感谢James Blaisdell、David Harrington、Alfred Hoenes、Russ Housley、Jeffrey Hutzelman、Kevin Igoe、Rob Lambert、Jan Pechanek、Tim Polk、Sean Turner、Nicolas Williams和ietf成员的有益评论-ssh@netbsd.org邮件列表。
Authors' Addresses
作者地址
Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia
玛格丽特昆士兰科技大学信息安全研究所7, 126级布里斯班昆士兰4000澳大利亚
EMail: douglas@stebila.ca
EMail: douglas@stebila.ca
Jon Green Queen's University Parallel Processing Research Laboratory Department of Electrical and Computer Engineering Room 614, Walter Light Hall Kingston, Ontario K7L 3N6 Canada
Jon Green皇后大学并行处理研究实验室电气和计算机工程系，加拿大安大略省金斯敦Walter Light Hall 614室K7L 3N6
EMail: jonathan.green@queensu.ca
EMail: jonathan.green@queensu.ca