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.
この文書は、セキュアシェル（SSH）トランスポートプロトコル内で使用するために楕円曲線暗号（ECC）に基づくアルゴリズムが記載されています。特に、それは、楕円曲線のDiffie-Hellmanの（ECDH）キー合意を指定し、SSHトランスポート層プロトコルで使用する楕円曲線メネゼス - ク-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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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 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トラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、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
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).
この文書では、セキュア・シェル・アーセナルに次の楕円曲線暗号アルゴリズムを追加：楕円曲線ディフィ - ヘルマン（ECDH）と楕円曲線デジタル署名アルゴリズム（ECDSA）、ならびに、セキュアハッシュアルゴリズムのSHA2ファミリを利用します。また、支持体は、楕円曲線メネゼス-ク-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.
、その小さな鍵のサイズおよび国家安全保障局（NSA）のスイートBでのインクルージョンに、楕円曲線暗号（ECC）が広く利用され、魅力的な公開鍵暗号になってきています。
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）、およびディフィー・ヘルマン（DH）鍵交換などの暗号に比べ、これらのスキームにECCばらつきが小さいキーサイズと同等のセキュリティを提供します。これは、それらを攻撃するために最もよく知られたアルゴリズムに基づいてsymmetric-と非対称鍵暗号のためのおおよその同等のキーサイズを与える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+ |
+-----------+------------------------------+-------+---------+
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]（[HMV04]、[ANSI-X9.62]で使用可能なECCに関する追加情報、および[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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で示されます。楕円曲線ドメインパラメータのセットは、N個のベース点Pによって生成された注文のグループを定義します
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- [識別子" バイト[N] ecc_key_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.
ストリング【識別子】楕円曲線ドメインパラメータの識別子です。この文字列の書式は、セクション6.1で指定されています。 REQUIREDとこのアルゴリズムで使用するための楕円曲線ドメインパラメータの推奨セットに関する情報は、セクション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節に見出すことができます。いくつかの楕円曲線ドメインパラメータを与え、ECCキー対は、秘密鍵（整数d）、および公開鍵（楕円曲線点Q）を含む生成することができます。
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]で指定されています。メッセージハッシュアルゴリズムは、ハッシュ関数[FIPS-180-3]のSHA2ファミリーからのものである必要があり、セクション6.2.1で指定された曲線の大きさに応じて選択されます。
Signatures are encoded as follows:
次のように署名がエンコードされます。
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
文字列 "ECDSA-sha2- [識別子]" 文字列ecdsa_signature_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.
ストリング【識別子】楕円曲線ドメインパラメータの識別子です。この文字列の書式は、セクション6.1で指定されています。 REQUIREDとこのアルゴリズムで使用するための楕円曲線ドメインパラメータの推奨セットに関する情報は、セクション10に記載されています。
The ecdsa_signature_blob value has the following specific encoding:
ecdsa_signature_blob値は以下の特定のエンコーディングがあります。
mpint r mpint s
mpint R mpint秒
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.
楕円曲線ディフィ - ヘルマン（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.
REQUIREDと、この方法で使用することを推奨します楕円曲線ドメインパラメータの詳細は、セクション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].
それらが送信される前に送信されなければならない楕円曲線公開鍵（ポイント）オクテットストリングに符号化されます。楕円曲線点とオクテットストリング間の変換は、セクション2.3.3および[SEC1]の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.
メッセージ番号SSH_MSG_KEX_ECDH_INITとSSH_MSG_KEX_ECDH_REPLYの仕様は、セクション7で発見されました。
The following is an overview of the key exchange process:
以下は、鍵交換プロセスの概要は次のとおりです。
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. *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文字列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_REPLY列K_S、サーバの公開ホストキーの文字列Q_S、サーバのはかない公開鍵オクテット文字列string交換ハッシュの署名
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.
楕円曲線メネゼス-ク-Vanstone著（ECMQV）鍵交換アルゴリズムは、2つのローカル楕円曲線鍵ペアおよび2つのリモート公開鍵から共有秘密を生成します。 [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 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.
ECCのホスト鍵をサポートする公開鍵アルゴリズムも選択できる場合SSH_MSG_KEXINITメッセージとアルゴリズムのネゴシエーション中に、ECMQV鍵交換方式のみを選択することができます。これは、この鍵交換方式での暗黙のサーバ認証を使用しているためです。この場合は、暗号化/署名することができる公開鍵アルゴリズムを必要とする鍵交換方法は[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].
それらが送信される前に送信されなければならない楕円曲線はかない公開鍵（ポイント）オクテットストリングに符号化されます。楕円曲線点とオクテットストリング間の変換は、セクション2.3.3および[SEC1]の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 ------------->
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.
メッセージ番号SSH_MSG_ECMQV_INITとSSH_MSG_ECMQV_REPLYの仕様はセクション7に見出すことができます。
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文字列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_REPLY列K_S、サーバの公開ホストキーの文字列Q_S、サーバのはかない公開鍵オクテット文字列文字列の共有秘密を使用してHに計算されたHMACタグ
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".
REQUIRED楕円曲線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）のASCII期間区切り10進表現である含む他のすべての楕円曲線に対する[ASN1]オブジェクト識別子（OID）サーバーのECCのホストキーに関連付けられている名前の曲線ドメインパラメータの。この識別子は、公開鍵フォーマット識別子と楕円曲線ドメインパラメータ識別子（又はメソッド名と楕円曲線ドメインパラメータ識別子）の連結、すなわち、SSHプロトコルアーキテクチャ[RFC4251]で指定された最大値を超えないように設けられて定義されています64文字;そうでなければ、その曲線の識別子は未定義であり、曲線は、本明細書ではサポートされていません。
A list of the REQUIRED and RECOMMENDED curves and their OIDs can be found in Section 10.
必須および推奨曲線とそのOIDのリストは、第10項に記載されています。
Note that implementations MUST use the string identifiers for the three REQUIRED NIST curves, even when an OID exists for that curve.
実装は、OIDは、その曲線のために存在する場合であっても、3つの必須NIST曲線の文字列識別子を使用しなければならないことに留意されたいです。
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公開鍵アルゴリズムは、公開鍵フォーマット識別子の家族によって指定されています。セクション6.1で定義されるように各識別子は、楕円曲線ドメインパラメータ識別子と文字列「ECDSA-sha2-」を連結したものです。必須および推奨曲線とそのOIDのリストは、第10項に記載されています。
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 |
+----------------+----------------+
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）の鍵交換は、メソッド名の家族によって定義されます。セクション6.1で定義されるように各メソッド名は、楕円曲線ドメインパラメータ識別子を持つ文字列「ECDH-sha2-」を連結したものです。必須および推奨曲線とそのOIDのリストは、第10項に記載されています。
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]。ハッシュアルゴリズムは、将来の文書で定義される他のアルゴリズムのためのスペースを確保するために、メソッド名に定義されています。使用されるSHA2ファミリーのアルゴリズムは、セクション6.2.1の表に従ったメソッド名で指定された名前のカーブの大きさに基づいて選択されます。
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.
「ECDH-sha2-」と楕円曲線ドメインパラメータのセットを指定する任意ように符号化されたASN.1のOIDの連結は、暗黙的に本明細書の下で登録されています。
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.
楕円曲線メネゼス-ク-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]。使用されるSHA2ファミリーのアルゴリズムは、6.2.1節の表に従って選択した公開鍵アルゴリズムによってECMQVで使用するために指定された名前付きカーブの大きさに基づいて選択されます。
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は、鍵交換固有とIANA登録処理を必要とせずに、任意のキー交換方法[RFC4253]で再定義することができる[RFC4250]で定義されたプライベート名前空間です。
The following message numbers have been defined in this document:
次のメッセージ番号は、この文書で定義されています。
#define SSH_MSG_KEX_ECDH_INIT 30
#define SSH_MSG_KEX_ECDH_REPLY 31
#define SSH_MSG_ECMQV_INIT 30
#define SSH_MSG_ECMQV_REPLY 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プロトコルは、公開鍵アルゴリズムおよび鍵交換方式のためのネゴシエーションメカニズムを提供します。この文書で定義されたアルゴリズムおよび方法を認識しない任意の実装がネゴシエーションでそれらを無視して次相互サポートアルゴリズムまたは方法を使用する、負の影響を生じません後方互換性の上。
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、有限ディフィー・ヘルマン、又は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を含む鍵交換を認証された）によって追加された機能のすべての3つのクラスでは、暗号を破るために、現在最もよく知られている技術は、（楕円曲線上の離散対数問題を解くことです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は複合体である場合、ワイル降下に基づいて、攻撃を受けやすいかもしれません。第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 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.)
曲線パラメータをランダムに生成された場合、曲線は特殊攻撃に耐性となり、最も一般的な攻撃に頼らなければならないこと（たとえば、[SEC1]のセクションB.2.1を参照）と考えられています。第10節で、必要な曲線は、すべての検証可能な擬似乱数として生成されました。一般的な攻撃のランタイムが使用されるアルゴリズムに依存します。現時点では、最もよく知られているアルゴリズムは、ポラード・ロー方式です。 （量子コンピュータ用ショアのアルゴリズムは多項式時間で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ビットの楕円曲線はとても（例えばREQUIRED nistp256曲線として）256ビットの楕円曲線は、例えば、128ビットのAESとの使用に適している、N / 2ビットの対称暗号と同様のセキュリティを提供します。
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アルゴリズムのセキュリティ問題に関する詳細な議論は、付録B [SEC1]に見出すことができます。
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は、SHA2ファミリには弱点が現時点で知られていません。 SHA-224、SHA-256、SHA-384、およびSHA-521 - - 彼らのダイジェスト長にちなんで名付けられたSHA2ファミリは、4つの亜種で構成されています。ハッシュ関数の具体的な構成を利用する特別な目的の攻撃が存在しない場合には、ハッシュ関数の衝突、preimages、及び第二preimagesを見つけることの難しさは、ダイジェストの長さに関連しています。この文書では、この指針に基づいた楕円曲線のサイズに使用する必要がありSHA2バリアント6.2.1節で指定します。
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 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とECMQVは、任意のサイズ、したがって、任意のセキュリティ強度の楕円曲線を可能にするので、楕円曲線のサイズはSSHハンドシェイクの他の要素のセキュリティ強度と一致するように選択することが重要です。具体的には、キーのサイズをホストする、ハッシュアルゴリズムおよびバルク暗号化アルゴリズムを適切に選択しなければなりません。キーのサイズの推定等価性に関する情報は[NIST-800-57]で利用可能です。 [RFC3766]での議論にも関連しています。我々は、ECDSAは、署名アルゴリズムとして使用され、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.
REQUIREDこの文書で推奨の曲線は、このセクションで示されるレベルで且つ第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.
REQUIREDまたは本書で推奨カーブ以外のカーブを有効にする場合、システム管理者と実装者はセキュリティ上の問題を慎重に検討を取る必要があります。必ずしもすべての楕円曲線は、彼らは大規模なフィールドの上にある場合でも、安全です。
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署名生成およびECDHとECMQVでエフェメラルプライベートキー値に使用される値kを含む - - 実装は、任意のエフェメラルプライベートキーまたはランダム値をことを確認する必要があり、乱数発生器又は適切に播種擬似乱数生成器から生成され、あります漏洩から保護され、この文書に記載されているプロトコルの文脈の外では再利用されず、不要になったときにメモリから消去されます。
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].
実装は、楕円曲線ドメインパラメータ[ASN1]のセットを定義ASN.1オブジェクトツリー内の任意の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カーブ]で定義されました。特にローカルセキュリティポリシーで無効にしない限り、これらの曲線は、常に有効にする必要があります。
+----------+-----------+---------------------+
| 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.)
*これらの3つの必須の曲線は、楕円曲線ドメインパラメータ識別子は、テーブルの最初の列、曲線の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 |
+----------+-----------+---------------------+
* 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.)
*これらの推奨の曲線は、楕円曲線ドメインパラメータ識別子は、テーブルの第3列、曲線のOIDのASCII表現の文字列です。 （6.1節を参照してください。）
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations:
[RFC4251]と[RFC4250]の4.6節の第8節と一致して、このドキュメントは以下の登録を行います
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.
公開鍵アルゴリズム名のレジストリで：第3節で定義された公開鍵アルゴリズムに名前を付けるために、SSH公開鍵アルゴリズム名の家族は「ECDSA-sha2-」で始まるとアットマーク（「@」）を含有しません。
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.
SSH鍵交換メソッド名の家族が「ECDH-sha2-」で始まるとアットマーク（「@」）を含有しない、第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]国際電気通信連合は、 "抽象構文記法1（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]アメリカ国立標準技術研究所、 "ハッシュ標準セキュア"、2008年10月、180-3をFIPS。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]レーティネン、S.とC. Lonvick、 "セキュアシェル（SSH）プロトコル割り当て番号"、RFC 4250、2006年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "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]効率的な暗号化グループのための基準、 "楕円曲線暗号"、SEC 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]効率的な暗号化グループのための基準、 "推奨楕円曲線ドメインパラメータ"、SEC 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.62、1998。
[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.、メネゼス、A.、およびS. Vanstone著、 "楕円曲線暗号のガイド"、スプリンガー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>.
[LMQSV98]法、L.、メネゼス、A.、屈原、M.、Solinas、J.、およびS. Vanstone著、 "認証鍵共有のための効率的なプロトコル"、大学ウォータールーテクニカルレポートCORR 98から05まで、1998年8月の、<のhttp：// www.cacr.math.uwaterloo.ca/techreports/1998/ corr98-05.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 Special Publication 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月、「連邦政府の使用のための楕円曲線を推奨します」。
Appendix A. Acknowledgements
付録A.謝辞
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.
著者はジェームズ・ブレイズデル、デヴィッド・ハリントン、アルフレッドHoenes、ラスHousley、ジェフリーHutzelman、ケビンIgoe、ロブ・ランバート、ヤンPechanek、ティムポーク、ショーン・ターナー、ニコラス・ウィリアムズ、そしてietf-ssh@netbsd.orgのメンバーから有益なコメントを認めますメーリングリスト。
Authors' Addresses
著者のアドレス
Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia
ダグラスStebilaクイーンズランド工科大学の情報セキュリティ研究所レベル7、126マーガレットセントブリスベン、クイーンズランド4000オーストラリア
EMail: douglas@stebila.ca
メールアドレス：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
電気およびコンピュータ工学室614のジョン・グリーンクイーンズ大学並列処理研究所部門、ウォルター・ライトホールキングストンオンタリオ州3N6カナダ
EMail: jonathan.green@queensu.ca
メールアドレス：jonathan.green@queensu.ca