[要約] RFC 6637は、OpenPGPにおける楕円曲線暗号（ECC）の使用を定義しています。この文書の目的は、デジタル署名と鍵交換のためのECCアルゴリズムの統合を提供し、これによりOpenPGPのセキュリティを強化し、効率を向上させることです。ECCは、より短い鍵長で同等のセキュリティレベルを提供するため、リソースが限られている環境や高速な処理が求められる場面で特に有用です。このRFCは、ECCの使用に関連する標準化された曲線やアルゴリズムを指定し、OpenPGPの実装におけるECCの採用を促進します。関連するRFCには、OpenPGPの基本を定義するRFC 4880や、後続の改良を扱うRFC 5581などがあります。
Internet Engineering Task Force (IETF) A. Jivsov
Request for Comments: 6637 Symantec Corporation
Category: Standards Track June 2012
ISSN: 2070-1721
Elliptic Curve Cryptography (ECC) in OpenPGP
OpenPGPでの楕円曲線暗号（ECC）
Abstract
概要
This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves.
このドキュメントでは、OpenPGP公開キー形式に対する楕円曲線暗号拡張を定義し、米国国立標準技術研究所が発行した標準を含む他の標準による幅広いサポートを受ける3つの楕円曲線を指定します。このドキュメントでは、この拡張機能を利用する準拠OpenPGP実装とこれらの楕円曲線との間の相互運用性に関する規則を規定しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6637.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6637で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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 Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions used in This Document ...............................3
3. Elliptic Curve Cryptography .....................................3
4. Supported ECC Curves ............................................3
5. Supported Public Key Algorithms .................................4
6. Conversion Primitives ...........................................4
7. Key Derivation Function .........................................5
8. EC DH Algorithm (ECDH) ..........................................5
9. Encoding of Public and Private Keys .............................8
10. Message Encoding with Public Keys ..............................9
11. ECC Curve OID .................................................10
12. Compatibility Profiles ........................................10
12.1. OpenPGP ECC Profile ......................................10
12.2. Suite-B Profile ..........................................11
12.2.1. Security Strength at 192 Bits .....................11
12.2.2. Security Strength at 128 Bits .....................11
13. Security Considerations .......................................12
14. IANA Considerations ...........................................14
15. References ....................................................14
15.1. Normative References .....................................14
15.2. Informative References ...................................15
16. Contributors ..................................................15
17. Acknowledgment ................................................15
The OpenPGP protocol [RFC4880] supports RSA and DSA (Digital Signature Algorithm) public key formats. This document defines the extension to incorporate support for public keys that are based on Elliptic Curve Cryptography (ECC).
OpenPGPプロトコル[RFC4880]は、RSAおよびDSA（デジタル署名アルゴリズム）公開鍵形式をサポートしています。このドキュメントは、Elliptic Curve Cryptography（ECC）に基づく公開鍵のサポートを組み込むための拡張機能を定義しています。
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]. Any implementation that adheres to the format and methods specified in this document is called a compliant application. Compliant applications are a subset of the broader set of OpenPGP applications described in [RFC4880]. Any [RFC2119] keyword within this document applies to compliant applications only.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。このドキュメントで指定されている形式とメソッドに準拠する実装は、準拠アプリケーションと呼ばれます。準拠アプリケーションは、[RFC4880]で説明されているOpenPGPアプリケーションの幅広いセットのサブセットです。このドキュメント内の[RFC2119]キーワードは、準拠しているアプリケーションにのみ適用されます。
This document establishes the minimum set of Elliptic Curve Cryptography (ECC) public key parameters and cryptographic methods that will likely satisfy the widest range of platforms and applications and facilitate interoperability. It adds a more efficient method for applications to balance the overall level of security with any AES algorithm specified in [RFC4880] than by simply increasing the size of RSA keys. This document defines a path to expand ECC support in the future.
このドキュメントは、最も幅広いプラットフォームとアプリケーションを満たし、相互運用性を促進する可能性が高い楕円曲線暗号（ECC）公開鍵パラメーターと暗号化メソッドの最小セットを確立します。これは、RSA鍵のサイズを単純に増やすよりも、[RFC4880]で指定されているすべてのAESアルゴリズムとセキュリティの全体的なレベルのバランスをとるための、より効率的な方法をアプリケーションに追加します。このドキュメントでは、将来的にECCサポートを拡張する方法を定義します。
The National Security Agency (NSA) of the United States specifies ECC for use in its [SuiteB] set of algorithms. This document includes algorithms required by Suite B that are not present in [RFC4880].
米国の国家安全保障局（NSA）は、[SuiteB]アルゴリズムのセットで使用するECCを指定しています。このドキュメントには、[RFC4880]にはないSuite Bに必要なアルゴリズムが含まれています。
[KOBLITZ] provides a thorough introduction to ECC.
[KOBLITZ]は、ECCを徹底的に紹介しています。
This document references three named prime field curves, defined in [FIPS-186-3] as "Curve P-256", "Curve P-384", and "Curve P-521".
このドキュメントは、[FIPS-186-3]で「曲線P-256」、「曲線P-384」、および「曲線P-521」として定義されている3つの名前付き素体曲線を参照しています。
The named curves are referenced as a sequence of bytes in this document, called throughout, curve OID. Section 11 describes in detail how this sequence of bytes is formed.
名前付き曲線は、このドキュメントでは一連のバイトとして参照され、全体を通して、曲線OIDと呼ばれます。セクション11では、このバイトシーケンスがどのように形成されるかを詳しく説明します。
The supported public key algorithms are the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-3] and the Elliptic Curve Diffie-Hellman (ECDH). A compatible specification of ECDSA is given in [RFC6090] as "KT-I Signatures" and in [SEC1]; ECDH is defined in Section 8 of this document.
サポートされている公開鍵アルゴリズムは、楕円曲線デジタル署名アルゴリズム（ECDSA）[FIPS-186-3]と楕円曲線Diffie-Hellman（ECDH）です。 ECDSAの互換性のある仕様は、[RFC6090]に「KT-I Signatures」として、および[SEC1]に記載されています。 ECDHは、このドキュメントのセクション8で定義されています。
The following public key algorithm IDs are added to expand Section 9.1 of [RFC4880], "Public-Key Algorithms":
[RFC4880]のセクション9.1、「公開鍵アルゴリズム」を拡張するために、次の公開鍵アルゴリズムIDが追加されています。
ID Description of Algorithm
-- --------------------------
18 ECDH public key algorithm
19 ECDSA public key algorithm
Compliant applications MUST support ECDSA and ECDH.
準拠アプリケーションは、ECDSAおよびECDHをサポートする必要があります。
This document only defines the uncompressed point format. The point is encoded in the Multiprecision Integer (MPI) format [RFC4880]. The content of the MPI is the following:
このドキュメントでは、非圧縮ポイント形式のみを定義しています。ポイントは、Multiprecision Integer（MPI）形式[RFC4880]でエンコードされます。 MPIの内容は次のとおりです。
B = 04 || x || y
B = 04 || x || y
where x and y are coordinates of the point P = (x, y), each encoded
in the big-endian format and zero-padded to the adjusted underlying
field size. The adjusted underlying field size is the underlying
field size that is rounded up to the nearest 8-bit boundary.
Therefore, the exact size of the MPI payload is 515 bits for "Curve P-256", 771 for "Curve P-384", and 1059 for "Curve P-521".
したがって、MPIペイロードの正確なサイズは、「Curve P-256」では515ビット、「Curve P-384」では771、「Curve P-521」では1059です。
Even though the zero point, also called the point at infinity, may occur as a result of arithmetic operations on points of an elliptic curve, it SHALL NOT appear in data structures defined in this document.
無限遠点とも呼ばれるゼロ点は、楕円曲線の点に対する算術演算の結果として発生する可能性がありますが、このドキュメントで定義されているデータ構造には表示されません。
This encoding is compatible with the definition given in [SEC1].
このエンコーディングは、[SEC1]で定義されている定義と互換性があります。
If other conversion methods are defined in the future, a compliant application MUST NOT use a new format when in doubt that any recipient can support it. Consider, for example, that while both the public key and the per-recipient ECDH data structure, respectively defined in Sections 9 and 10, contain an encoded point field, the format changes to the field in Section 10 only affect a given recipient of a given message.
他の変換方法が将来的に定義される場合、準拠するアプリケーションは、受信者がそれをサポートできるかどうか疑わしいときに、新しい形式を使用してはなりません。たとえば、セクション9と10でそれぞれ定義されている公開鍵と受信者ごとのECDHデータ構造の両方にエンコードされたポイントフィールドが含まれている場合、セクション10のフィールドへのフォーマットの変更は、与えられたメッセージ。
A key derivation function (KDF) is necessary to implement the EC encryption. The Concatenation Key Derivation Function (Approved Alternative 1) [NIST-SP800-56A] with the KDF hash function that is SHA2-256 [FIPS-180-3] or stronger is REQUIRED. See Section 12 for the details regarding the choice of the hash function.
EC暗号化を実装するには、鍵導出関数（KDF）が必要です。 SHA2-256 [FIPS-180-3]以上のKDFハッシュ関数を使用した連結キー導出関数（承認済みの代替1）[NIST-SP800-56A]が必要です。ハッシュ関数の選択に関する詳細については、セクション12を参照してください。
For convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document. However, [NIST-SP800-56A] is the normative source of the definition.
便宜上、エンコード方法の概要を以下に示します。このドキュメントでは、ハッシュ関数の選択が制限されているため、大幅に簡略化されています。ただし、[NIST-SP800-56A]は定義の規範的な情報源です。
// Implements KDF( X, oBits, Param );
// Input: point X = (x,y)
// oBits - the desired size of output
// hBits - the size of output of hash function Hash
// Param - octets representing the parameters
// Assumes that oBits <= hBits
// Convert the point X to the octet string, see section 6:
// ZB' = 04 || x || y
// and extract the x portion from ZB'
ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB.
Note that ZB in the KDF description above is the compact representation of X, defined in Section 4.2 of [RFC6090].
上記のKDFの説明のZBは、[RFC6090]のセクション4.2で定義されているXのコンパクトな表現であることに注意してください。
The method is a combination of an ECC Diffie-Hellman method to establish a shared secret, a key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message.
この方法は、共有シークレットを確立するECC Diffie-Hellmanメソッド、共有シークレットを派生キーに処理するキー派生メソッド、および派生キーを使用して暗号化に使用されるセッションキーを保護するキーラッピングメソッドの組み合わせです。メッセージ。
The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [NIST-SP800-56A] MUST be implemented with the following restrictions: the ECC CDH primitive employed by this method is modified to always assume the cofactor as 1, the KDF specified in Section 7 is used, and the KDF parameters specified below are used.
ワンパスDiffie-Hellman方式C（1、1、ECC CDH）[NIST-SP800-56A]は、次の制限付きで実装する必要があります。セクション7で指定されたKDFが使用され、以下で指定されたKDFパラメーターが使用されます。
The KDF parameters are encoded as a concatenation of the following 5 variable-length and fixed-length fields, compatible with the definition of the OtherInfo bitstring [NIST-SP800-56A]:
KDFパラメータは、OtherInfoビット文字列[NIST-SP800-56A]の定義と互換性のある、次の5つの可変長フィールドと固定長フィールドの連結としてエンコードされます。
o a variable-length field containing a curve OID, formatted as follows:
o 次のようなフォーマットの曲線OIDを含む可変長フィールド：
- a one-octet size of the following field
- 次のフィールドの1オクテットのサイズ
- the octets representing a curve OID, defined in Section 11
- セクション11で定義された曲線OIDを表すオクテット
o a one-octet public key algorithm ID defined in Section 5
o セクション5で定義された1オクテットの公開鍵アルゴリズムID
o a variable-length field containing KDF parameters, identical to the corresponding field in the ECDH public key, formatted as follows:
o ECDH公開鍵の対応するフィールドと同じ、KDFパラメータを含む可変長フィールド。次の形式です。
- a one-octet size of the following fields; values 0 and 0xff are reserved for future extensions
- 次のフィールドの1オクテットサイズ。値0および0xffは、将来の拡張のために予約されています
- a one-octet value 01, reserved for future extensions
- 1オクテットの値01、将来の拡張用に予約
- a one-octet hash function ID used with the KDF
- KDFで使用される1オクテットのハッシュ関数ID
- a one-octet algorithm ID for the symmetric algorithm used to wrap the symmetric key for message encryption; see Section 8 for details
- メッセージ暗号化の対称鍵をラップするために使用される対称アルゴリズムの1オクテットアルゴリズムID。詳細はセクション8を参照
o 20 octets representing the UTF-8 encoding of the string "Anonymous Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20
o 文字列「Anonymous Sender」のUTF-8エンコーディングを表す20オクテット。これはオクテットシーケンス41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20
o 20 octets representing a recipient encryption subkey or a master key fingerprint, identifying the key material that is needed for the decryption
o 受信者の暗号化サブキーまたはマスターキーフィンガープリントを表す20オクテット。復号化に必要なキーマテリアルを識別します。
The size of the KDF parameters sequence, defined above, is either 54 or 51 for the three curves defined in this document.
上記で定義されているKDFパラメータシーケンスのサイズは、このドキュメントで定義されている3つの曲線に対して54または51です。
The key wrapping method is described in [RFC3394]. KDF produces a symmetric key that is used as a key-encryption key (KEK) as specified in [RFC3394]. Refer to Section 13 for the details regarding the choice of the KEK algorithm, which SHOULD be one of three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394].
鍵のラップ方法は[RFC3394]で説明されています。 [RFC3394]で指定されているように、KDFはキー暗号化キー（KEK）として使用される対称キーを生成します。 KEKアルゴリズムの選択に関する詳細については、セクション13を参照してください。KEKアルゴリズムは、3つのAESアルゴリズムの1つである必要があります（SHOULD）。鍵のラッピングとアンラッピングは、デフォルトの初期値[RFC3394]で実行されます。
The input to the key wrapping method is the value "m" derived from the session key, as described in Section 5.1 of [RFC4880], "Public-Key Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5 (Public-Key Cryptography Standards version 1.5) padding step is omitted. The result is padded using the method described in [PKCS5] to the 8-byte granularity. For example, the following AES-256 session key, in which 32 octets are denoted from k0 to k31, is composed to form the following 40 octet sequence:
キーラッピングメソッドへの入力は、[RFC4880]のセクション5.1、「公開キー暗号化セッションキーパケット（タグ1）」で説明されているように、セッションキーから派生した値「m」ですが、PKCS＃1.5（公開鍵暗号化標準バージョン1.5）パディング手順は省略されます。結果は、[PKCS5]で説明されている方法を使用して、8バイトの粒度にパディングされます。たとえば、次のAES-256セッションキーは、k0からk31までの32オクテットを表し、次の40オクテットシーケンスを形成するように構成されています。
09 k0 k1 ... k31 c0 c1 05 05 05 05 05
09 k0 k1 ... k31 c0 c1 05 05 05 05 05
The octets c0 and c1 above denote the checksum. This encoding allows the sender to obfuscate the size of the symmetric encryption key used to encrypt the data. For example, assuming that an AES algorithm is used for the session key, the sender MAY use 21, 13, and 5 bytes of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.
上記のオクテットc0およびc1はチェックサムを示します。このエンコードにより、送信者はデータの暗号化に使用される対称暗号化キーのサイズを難読化できます。たとえば、セッションキーにAESアルゴリズムが使用されると仮定すると、送信者は、AES-128、AES-192、およびAES-256にそれぞれ21、13、および5バイトのパディングを使用して、同じ数のキーラッピングメソッドへの入力としてのオクテット、合計40。
The output of the method consists of two fields. The first field is the MPI containing the ephemeral key used to establish the shared secret. The second field is composed of the following two fields:
メソッドの出力は2つのフィールドで構成されます。最初のフィールドは、共有秘密を確立するために使用される一時鍵を含むMPIです。 2番目のフィールドは、次の2つのフィールドで構成されています。
o a one-octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions
o キーラッピングメソッドの結果のオクテット単位のサイズを1オクテットでエンコードします。値255は将来の拡張のために予約されています
o up to 254 octets representing the result of the key wrapping method, applied to the 8-byte padded session key, as described above
o 上記のように、8バイトのパディングされたセッションキーに適用される、キーラッピングメソッドの結果を表す最大254オクテット
Note that for session key sizes 128, 192, and 256 bits, the size of the result of the key wrapping method is, respectively, 32, 40, and 48 octets, unless the size obfuscation is used.
セッションキーサイズが128、192、および256ビットの場合、サイズの難読化を使用しない限り、キーラッピングメソッドの結果のサイズは、それぞれ32、40、および48オクテットであることに注意してください。
For convenience, the synopsis of the encoding method is given below; however, this section, [NIST-SP800-56A], and [RFC3394] are the normative sources of the definition.
便宜上、エンコーディング方法の概要を以下に示します。ただし、このセクション、[NIST-SP800-56A]、および[RFC3394]は、定義の標準的な情報源です。
Obtain the authenticated recipient public key R
Generate an ephemeral key pair {v, V=vG}
Compute the shared point S = vR;
m = symm_alg_ID || session key || checksum || pkcs5_padding;
curve_OID_len = (byte)len(curve_OID);
Param = curve_OID_len || curve_OID || public_key_alg_ID || 03
|| 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous
Sender " || recipient_fingerprint;
Z_len = the key size for the KEK_alg_ID used with AESKeyWrap
Compute Z = KDF( S, Z_len, Param );
Compute C = AESKeyWrap( Z, m ) as per [RFC3394]
VB = convert point V to the octet string
Output (MPI(VB) || len(C) || C).
The decryption is the inverse of the method given. Note that the recipient obtains the shared secret by calculating
復号化は、指定された方法の逆です。受信者が計算することによって共有秘密を取得することに注意してください
S = rV = rvG, where (r,R) is the recipient's key pair.
S = rV = rvG、（r、R）は受信者の鍵ペアです。
Consistent with Section 5.13 of [RFC4880], "Sym. Encrypted Integrity Protected Data Packet (Tag 18)", a Modification Detection Code (MDC) MUST be used anytime the symmetric key is protected by ECDH.
[RFC4880]のセクション5.13「Sym。Encrypted Integrity Protected Data Packet（Tag 18）」に従い、対称鍵がECDHによって保護されている場合は常に修正検出コード（MDC）を使用する必要があります。
The following algorithm-specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support ECDH and ECDSA.
ECDHおよびECDSAをサポートするために、次のアルゴリズム固有のパケットが[RFC4880]のセクション5.5.2の「公開鍵パケット形式」に追加されました。
This algorithm-specific portion is:
このアルゴリズム固有の部分は次のとおりです。
Algorithm-Specific Fields for ECDSA keys:
ECDSA鍵のアルゴリズム固有のフィールド：
o a variable-length field containing a curve OID, formatted as follows:
o 次のようなフォーマットの曲線OIDを含む可変長フィールド：
- a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions
- 次のフィールドの1オクテットサイズ。値0および0xFFは、将来の拡張のために予約されています
- octets representing a curve OID, defined in Section 11
- セクション11で定義された曲線OIDを表すオクテット
o MPI of an EC point representing a public key
o 公開鍵を表すECポイントのMPI
Algorithm-Specific Fields for ECDH keys:
ECDHキーのアルゴリズム固有のフィールド：
o a variable-length field containing a curve OID, formatted as follows:
o 次のようなフォーマットの曲線OIDを含む可変長フィールド：
- a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions
- 次のフィールドの1オクテットサイズ。値0および0xFFは、将来の拡張のために予約されています
- the octets representing a curve OID, defined in Section 11
- セクション11で定義された曲線OIDを表すオクテット
- MPI of an EC point representing a public key
- 公開鍵を表すECポイントのMPI
o a variable-length field containing KDF parameters, formatted as follows:
o 次のようにフォーマットされた、KDFパラメーターを含む可変長フィールド：
- a one-octet size of the following fields; values 0 and 0xff are reserved for future extensions
- 次のフィールドの1オクテットサイズ。値0および0xffは、将来の拡張のために予約されています
- a one-octet value 01, reserved for future extensions
- 1オクテットの値01、将来の拡張用に予約
- a one-octet hash function ID used with a KDF
- KDFで使用される1オクテットのハッシュ関数ID
- a one-octet algorithm ID for the symmetric algorithm used to wrap the symmetric key used for the message encryption; see Section 8 for details
- メッセージの暗号化に使用される対称鍵をラップするために使用される対称アルゴリズムの1オクテットのアルゴリズムID。詳細はセクション8を参照
Observe that an ECDH public key is composed of the same sequence of fields that define an ECDSA key, plus the KDF parameters field.
ECDH公開鍵は、ECDSA鍵を定義するのと同じ一連のフィールドと、KDFパラメータフィールドで構成されていることに注意してください。
The following algorithm-specific packets are added to Section 5.5.3. of [RFC4880], "Secret-Key Packet Formats", to support ECDH and ECDSA.
次のアルゴリズム固有のパケットがセクション5.5.3に追加されています。 ECDHおよびECDSAをサポートするための[RFC4880]の「Secret-Key Packet Formats」。
Algorithm-Specific Fields for ECDH or ECDSA secret keys:
ECDHまたはECDSA秘密鍵のアルゴリズム固有のフィールド：
o an MPI of an integer representing the secret key, which is a scalar of the public EC point
o 公開ECポイントのスカラーである秘密鍵を表す整数のMPI
Section 5.2.2 of [RFC4880], "Version 3 Signature Packet Format" defines signature formats. No changes in the format are needed for ECDSA.
[RFC4880]のセクション5.2.2の「Version 3 Signature Packet Format」は、署名フォーマットを定義しています。 ECDSAの場合、形式を変更する必要はありません。
Section 5.1 of [RFC4880], "Public-Key Encrypted Session Key Packets (Tag 1)" is extended to support ECDH. The following two fields are the result of applying the KDF, as described in Section 8.
[RFC4880]のセクション5.1、「公開キー暗号化セッションキーパケット（タグ1）」はECDHをサポートするように拡張されています。次の2つのフィールドは、セクション8で説明されているように、KDFを適用した結果です。
Algorithm-Specific Fields for ECDH:
ECDHのアルゴリズム固有のフィールド：
o an MPI of an EC point representing an ephemeral public key
o 一時的な公開鍵を表すECポイントのMPI
o a one-octet size, followed by a symmetric key encoded using the method described in Section 8
o 1オクテットサイズ、セクション8で説明する方法を使用してエンコードされた対称キー
The parameter curve OID is an array of octets that define a named curve. The table below specifies the exact sequence of bytes for each named curve referenced in this document:
パラメータカーブOIDは、名前付きカーブを定義するオクテットの配列です。次の表は、このドキュメントで参照されている各名前付き曲線の正確なバイトシーケンスを示しています。
ASN.1 Object OID Curve OID bytes in Curve name in Identifier len hexadecimal [FIPS-186-3] representation
ASN.1 Object OID Curve OID bytes in Curve name in Identifier len 16進数[FIPS-186-3]表現
1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST curve P-256
1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST曲線P-256
1.3.132.0.34 5 2B 81 04 00 22 NIST curve P-384
1.3.132.0.34 5 2B 81 04 00 22 NIST曲線P-384
1.3.132.0.35 5 2B 81 04 00 23 NIST curve P-521
1.3.132.0.35 5 2B 81 04 00 23 NIST曲線P-521
The sequence of octets in the third column is the result of applying the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field is the length of the Object Identifier body. For example, the complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A 86 48 CE 3D 03 01 07", from which the first entry in the table above is constructed by omitting the first two octets. Only the truncated sequence of octets is the valid representation of a curve OID.
3列目のオクテットのシーケンスは、Distinguished Encoding Rules（DER）をASN.1 Object Identifierに適用し、その後に切り捨てた結果です。切り捨てにより、エンコードされたオブジェクト識別子の2つのフィールドが削除されます。最初に省略されたフィールドはオブジェクト識別子タグを表す1オクテットであり、2番目に省略されたフィールドはオブジェクト識別子本体の長さです。たとえば、NIST P-256カーブOIDの完全なASN.1 DERエンコードは「06 08 2A 86 48 CE 3D 03 01 07」で、上記の表の最初のエントリは最初の2つのオクテットを省略して作成されます。切り捨てられたオクテットのシーケンスのみが、曲線OIDの有効な表現です。
A compliant application MUST implement NIST curve P-256, MAY implement NIST curve P-384, and SHOULD implement NIST curve P-521, as defined in Section 11. A compliant application MUST implement SHA2-256 and SHOULD implement SHA2-384 and SHA2-512. A compliant application MUST implement AES-128 and SHOULD implement AES-256.
準拠アプリケーションは、セクション11で定義されているように、NIST曲線P-256を実装する必要があり、NIST曲線P-384を実装する必要があります。また、SHOULDは、NIST曲線P-521を実装する必要があります。 -512。準拠アプリケーションはAES-128を実装する必要があり、AES-256を実装する必要があります（SHOULD）。
A compliant application SHOULD follow Section 13 regarding the choice of the following algorithms for each curve:
準拠するアプリケーションは、各曲線に対する次のアルゴリズムの選択に関してセクション13に従う必要があります。
o the KDF hash algorithm
o KDFハッシュアルゴリズム
o the KEK algorithm
o KEKアルゴリズム
o the message digest algorithm and the hash algorithm used in the key certifications
o キー証明書で使用されるメッセージダイジェストアルゴリズムとハッシュアルゴリズム
o the symmetric algorithm used for message encryption.
o メッセージの暗号化に使用される対称アルゴリズム。
It is recommended that the chosen symmetric algorithm for message encryption be no less secure than the KEK algorithm.
メッセージ暗号化に選択した対称アルゴリズムは、KEKアルゴリズムと同等以上の安全性を確保することをお勧めします。
A subset of algorithms allowed by this document can be used to achieve [SuiteB] compatibility. The references to [SuiteB] in this document are informative. This document is primarily concerned with format specification, leaving additional security restrictions unspecified, such as matching the assigned security level of information to authorized recipients or interoperability concerns arising from fewer allowed algorithms in [SuiteB] than allowed by [RFC4880].
このドキュメントで許可されているアルゴリズムのサブセットを使用して、[SuiteB]互換性を実現できます。このドキュメントでの[SuiteB]への参照は参考情報です。このドキュメントは主にフォーマット仕様に関連しており、割り当てられた情報のセキュリティレベルを許可された受信者に一致させる、[SuiteB]で許可されているアルゴリズムが[RFC4880]で許可されているよりも少ないために生じる相互運用性の懸念など、追加のセキュリティ制限は指定していません。
To achieve the security strength of 192 bits, [SuiteB] requires NIST curve P-384, AES-256, and SHA2-384. The symmetric algorithm restriction means that the algorithm of KEK used for key wrapping in Section 8 and an [RFC4880] session key used for message encryption must be AES-256. The hash algorithm restriction means that the hash algorithms of KDF and the [RFC4880] message digest calculation must be SHA-384.
192ビットのセキュリティ強度を実現するには、[SuiteB]にNIST曲線P-384、AES-256、およびSHA2-384が必要です。対称アルゴリズムの制限は、セクション8でキーラッピングに使用されるKEKのアルゴリズムと、メッセージの暗号化に使用される[RFC4880]セッションキーがAES-256であることを意味します。ハッシュアルゴリズムの制限は、KDFのハッシュアルゴリズムと[RFC4880]メッセージダイジェスト計算がSHA-384でなければならないことを意味します。
The set of algorithms in Section 12.2.1 is extended to allow NIST curve P-256, AES-128, and SHA2-256.
セクション12.2.1のアルゴリズムのセットは、NISTカーブP-256、AES-128、およびSHA2-256を許可するように拡張されています。
Refer to [FIPS-186-3], B.4.1, for the method to generate a uniformly distributed ECC private key.
均一に分散されたECC秘密鍵を生成する方法については、[FIPS-186-3]、B.4.1を参照してください。
The curves proposed in this document correspond to the symmetric key sizes 128 bits, 192 bits, and 256 bits, as described in the table below. This allows a compliant application to offer balanced public key security, which is compatible with the symmetric key strength for each AES algorithm allowed by [RFC4880].
このドキュメントで提案されている曲線は、以下の表に示すように、128ビット、192ビット、および256ビットの対称キーのサイズに対応しています。これにより、準拠アプリケーションはバランスの取れた公開鍵セキュリティを提供できます。これは、[RFC4880]で許可されている各AESアルゴリズムの対称鍵の強度に対応しています。
The following table defines the hash and the symmetric encryption algorithm that SHOULD be used with a given curve for ECDSA or ECDH. A stronger hash algorithm or a symmetric key algorithm MAY be used for a given ECC curve. However, note that the increase in the strength of the hash algorithm or the symmetric key algorithm may not increase the overall security offered by the given ECC key.
次の表は、ECDSAまたはECDHの特定の曲線で使用する必要があるハッシュと対称暗号化アルゴリズムを定義しています。より強力なハッシュアルゴリズムまたは対称鍵アルゴリズムを、特定のECC曲線に使用できます。ただし、ハッシュアルゴリズムまたは対称キーアルゴリズムの強度を上げても、特定のECCキーによって提供される全体的なセキュリティが向上しない場合があることに注意してください。
Curve name ECC RSA Hash size Symmetric strength strength, key size informative
曲線名ECC RSAハッシュサイズ対称強度強度、キーサイズの情報
NIST curve P-256 256 3072 256 128
NIST曲線P-256 256 3072 256128
NIST curve P-384 384 7680 384 192
NIST曲線P-384 384 7680 384 192
NIST curve P-521 521 15360 512 256
NIST曲線P-521 521 15360 512 256
Requirement levels indicated elsewhere in this document lead to the following combinations of algorithms in the OpenPGP profile: MUST implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve P-384 / SHA2-384 / AES-256, among other allowed combinations.
このドキュメントの他の場所で示されている要件レベルは、OpenPGPプロファイルで次のアルゴリズムの組み合わせにつながります：NIST曲線P-256 / SHA2-256 / AES-128を実装する必要があります。NIST曲線P-521 / SHA2-512 / AES-256を実装する必要があります、他の許可された組み合わせの中で、NIST曲線P-384 / SHA2-384 / AES-256を実装してもよい（MAY）。
Consistent with the table above, the following table defines the KDF hash algorithm and the AES KEK encryption algorithm that SHOULD be used with a given curve for ECDH. A stronger KDF hash algorithm or AES KEK algorithm MAY be used for a given ECC curve.
上記の表と一致して、次の表はECDFの特定の曲線で使用する必要があるKDFハッシュアルゴリズムとAES KEK暗号化アルゴリズムを定義しています。より強力なKDFハッシュアルゴリズムまたはAES KEKアルゴリズムが、特定のECC曲線に使用される場合があります。
Curve name Recommended KDF Recommended KEK hash algorithm encryption algorithm
曲線名推奨KDF推奨KEKハッシュアルゴリズム暗号化アルゴリズム
NIST curve P-256 SHA2-256 AES-128
NIST曲線P-256 SHA2-256 AES-128
NIST curve P-384 SHA2-384 AES-192
NISTカーブP-384 SHA2-384 AES-192
NIST curve P-521 SHA2-512 AES-256 This document explicitly discourages the use of algorithms other than AES as a KEK algorithm because backward compatibility of the ECDH format is not a concern. The KEK algorithm is only used within the scope of a Public-Key Encrypted Session Key Packet, which represents an ECDH key recipient of a message. Compare this with the algorithm used for the session key of the message, which MAY be different from a KEK algorithm.
NIST曲線P-521 SHA2-512 AES-256このドキュメントでは、ECDH形式の下位互換性が問題にならないため、KESアルゴリズムとしてAES以外のアルゴリズムを使用しないことを明示的に推奨しています。 KEKアルゴリズムは、メッセージのECDHキー受信者を表す公開キー暗号化セッションキーパケットのスコープ内でのみ使用されます。これを、メッセージのセッションキーに使用されるアルゴリズムと比較してください。これは、KEKアルゴリズムとは異なる場合があります。
Compliant applications SHOULD implement, advertise through key preferences, and use in compliance with [RFC4880], the strongest algorithms specified in this document.
準拠アプリケーションは、このドキュメントで指定されている最も強力なアルゴリズムである[RFC4880]に準拠して実装し、主要な設定を介して宣伝し、使用する必要があります。
Note that the [RFC4880] symmetric algorithm preference list may make it impossible to use the balanced strength of symmetric key algorithms for a corresponding public key. For example, the presence of the symmetric key algorithm IDs and their order in the key preference list affects the algorithm choices available to the encoding side, which in turn may make the adherence to the table above infeasible. Therefore, compliance with this specification is a concern throughout the life of the key, starting immediately after the key generation when the key preferences are first added to a key. It is generally advisable to position a symmetric algorithm ID of strength matching the public key at the head of the key preference list.
[RFC4880]対称アルゴリズムの優先リストでは、対応する公開鍵に対称鍵アルゴリズムのバランスの取れた強度を使用できない場合があることに注意してください。たとえば、対称キーアルゴリズムIDの存在とキー優先リスト内のそれらの順序は、エンコード側で利用可能なアルゴリズムの選択に影響を与え、その結果、上記の表を順守することが不可能になる場合があります。したがって、この仕様への準拠は、キーの有効期間全体にわたって懸念事項であり、キーの設定が最初にキーに追加されるキー生成の直後から始まります。一般に、公開鍵に一致する強度の対称アルゴリズムIDを鍵優先リストの先頭に配置することをお勧めします。
Encryption to multiple recipients often results in an unordered intersection subset. For example, if the first recipient's set is {A, B} and the second's is {B, A}, the intersection is an unordered set of two algorithms, A and B. In this case, a compliant application SHOULD choose the stronger encryption algorithm.
複数の受信者を暗号化すると、多くの場合、順序付けされていない交差サブセットが生成されます。たとえば、最初の受信者のセットが{A、B}で、2番目の受信者のセットが{B、A}の場合、交差は2つのアルゴリズムAとBの順序付けされていないセットです。この場合、準拠アプリケーションはより強力な暗号化を選択する必要があります（SHOULD）アルゴリズム。
Resource constraints, such as limited computational power, is a likely reason why an application might prefer to use the weakest algorithm. On the other side of the spectrum are applications that can implement every algorithm defined in this document. Most applications are expected to fall into either of two categories. A compliant application in the second, or strongest, category SHOULD prefer AES-256 to AES-192.
限られた計算能力などのリソースの制約は、アプリケーションが最も弱いアルゴリズムを使用することを好む理由の可能性があります。スペクトルの反対側には、このドキュメントで定義されているすべてのアルゴリズムを実装できるアプリケーションがあります。ほとんどのアプリケーションは、2つのカテゴリのいずれかに分類されると予想されます。 2番目、または最も強力なカテゴリの準拠アプリケーションは、AES-192よりもAES-256を優先する必要があります（SHOULD）。
SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
SHA-1は、ECDHAまたはECDHメソッドのKDFと共に使用してはなりません（MUST NOT）。
MDC MUST be used when a symmetric encryption key is protected by ECDH. None of the ECC methods described in this document are allowed with deprecated V3 keys. A compliant application MUST only use iterated and salted S2K to protect private keys, as defined in Section 3.7.1.3 of [RFC4880], "Iterated and Salted S2K".
対称暗号化キーがECDHによって保護されている場合は、MDCを使用する必要があります。このドキュメントで説明されているECCメソッドはいずれも、非推奨のV3キーでは許可されていません。 [RFC4880]のセクション3.7.1.3の「反復およびソルトS2K」で定義されているように、準拠アプリケーションは反復およびソルトS2Kのみを使用して秘密鍵を保護する必要があります。
Side channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing oracle model, for example, when an application is a network service performing decryption to unauthenticated remote users. ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side channel attacks. Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding of the operations associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations.
サイドチャネル攻撃は、たとえばアプリケーションが認証されていないリモートユーザーに対して復号化を実行するネットワークサービスである場合など、準拠アプリケーションのOpenPGP形式の使用が復号化または署名オラクルモデルによってモデル化できる場合の懸念事項です。 ECDSAおよびECDHで使用されるECCスカラー乗算演算は、サイドチャネル攻撃に対して脆弱です。多くの場合、許容される障害の数を制限したり、各ネットワークインターフェイスに関連する操作の時間をブラインドしたりするなど、より高いプロトコルレベルで対策を講じることができます。スカラー倍レベルの緩和策は、ECCポイントの加算と倍演算の測定可能な違いを排除しようとするものです。
Per this document, IANA has assigned an algorithm number from the "Public Key Algorithms" range (or the "name space" in the terminology of [RFC5226]) of the "Pretty Good Privacy (PGP)" registry, created by [RFC4880]. Two ID numbers have been assigned, as defined in Section 5. The first one, value 19, is already designated for ECDSA and is currently unused, while the other one, value 18, is new.
このドキュメントによれば、IANAは、[RFC4880]によって作成された「Pretty Good Privacy（PGP）」レジストリの「Public Key Algorithms」範囲（または[RFC5226]の用語では「名前空間」）からアルゴリズム番号を割り当てました。 。セクション5で定義されているように、2つのID番号が割り当てられています。最初のID値19はすでにECDSA用に指定されており、現在使用されていません。もう1つは新しい値18です。
[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月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。
[SuiteB] National Security Agency, "NSA Suite B Cryptography", March 11, 2010, http://www.nsa.gov/ia/programs/suiteb_cryptography/.
[SuiteB] National Security Agency、「NSA Suite B Cryptography」、2010年3月11日、http：//www.nsa.gov/ia/programs/suiteb_cryptography/。
[FIPS-186-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard", FIPS 186-3, June 2009.
[FIPS-186-3]米国国立標準技術研究所、米国商務省、「デジタル署名標準」、FIPS 186-3、2009年6月。
[NIST-SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 1, March 2007.
[NIST-SP800-56A] Barker、E.、Johnson、D。、およびM. Smid、「離散対数暗号化を使用したペアワイズキー確立スキームの推奨」、NIST Special Publication 800-56A Revision 1、2007年3月。
[FIPS-180-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.
[FIPS-180-3]米国国立標準技術研究所、米国商務省、「Secure Hash Standard（SHS）」、FIPS 180-3、2008年10月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based Cryptography Standard", March 25, 1999.
[PKCS5] RSA Laboratories、「PKCS＃5 v2.0：Password-Based Cryptography Standard」、1999年3月25日。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[KOBLITZ] N. Koblitz, "A course in number theory and cryptography", Chapter VI. Elliptic Curves, ISBN: 0-387-96576-9, Springer-Verlag, 1987
[コブリッツ] N.コブリッツ、「数論と暗号のコース」、第VI章。楕円曲線、ISBN：0-387-96576-9、Springer-Verlag、1987
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", September 2000.
[SEC1] Standards for Efficient Cryptography Group、「SEC 1：Elliptic Curve Cryptography」、2000年9月。
Hal Finney provided important criticism on compliance with [NIST-SP800-56A] and [SuiteB], and pointed out a few other mistakes.
Hal Finneyは、[NIST-SP800-56A]および[SuiteB]への準拠について重要な批判を述べ、他のいくつかの間違いを指摘しました。
The author would like to acknowledge the help of many individuals who kindly voiced their opinions on the IETF OpenPGP Working Group mailing list, in particular, the help of Jon Callas, David Crick, Ian G, Werner Koch, and Marko Kreen.
著者は、IETF OpenPGPワーキンググループメーリングリストで意見を述べてくれた多くの個人の助け、特にJon Callas、David Crick、Ian G、Werner Koch、およびMarko Kreenの助けを認めたいと思います。
Author's Address
著者のアドレス
Andrey Jivsov Symantec Corporation EMail: Andrey_Jivsov@symantec.com
Andrey Jivsov Symantec Corporationメール：Andrey_Jivsov@symantec.com