Internet Engineering Task Force (IETF) A. Jivsov
Request for Comments: 6637 Symantec Corporation
Category: Standards Track June 2012
ISSN: 2070-1721
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公钥格式的椭圆曲线加密扩展，并指定了三条椭圆曲线，它们受到其他标准的广泛支持，包括美国国家标准与技术研究所发布的标准。该文档指定了使用此扩展和这些椭圆曲线的兼容OpenPGP实现之间的互操作性约定。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2012 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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（数字签名算法）公钥格式。本文档定义了扩展，以包含对基于椭圆曲线加密（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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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）公钥参数和加密方法的最小集合，这些参数和方法可能满足最广泛的平台和应用程序，并促进互操作性。它为应用程序添加了一种更有效的方法，即使用[RFC4880]中指定的任何AES算法来平衡整体安全级别，而不是简单地增加RSA密钥的大小。本文档定义了将来扩展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）指定ECC用于其[SuiteB]算法集。本文件包括[RFC4880]中没有的套件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”的三条命名基本场曲线。
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）。[RFC6090]中给出了ECDSA的兼容规范，称为“KT-I签名”和[SEC1]；ECDH的定义见本文件第8节。
The following public key algorithm IDs are added to expand Section 9.1 of [RFC4880], "Public-Key Algorithms":
添加以下公钥算法ID是为了扩展[RFC4880]第9.1节“公钥算法”：
ID Description of Algorithm
-- --------------------------
18 ECDH public key algorithm
19 ECDSA public key algorithm
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:
本文档仅定义未压缩的点格式。该点以多精度整数（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.
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有效载荷的准确大小为“曲线P-256”515位，“曲线P-384”771位，“曲线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.
密钥派生函数（KDF）是实现EC加密所必需的。需要具有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.
// 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]必须在以下限制条件下实施：该方法使用的ECC-CDH原语被修改为始终假定辅因子为1，使用第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参数编码为以下5个可变长度和固定长度字段的串联，与OtherInfo位字符串[NIST-SP800-56A]的定义兼容：
o a variable-length field containing a curve OID, formatted as follows:
o 包含曲线OID的可变长度字段，格式如下：
- a one-octet size of the following field
- 以下字段的一个八位字节大小
- the octets representing a curve OID, defined in Section 11
- 表示曲线OID的八位字节，定义见第11节
o a one-octet public key algorithm ID defined in Section 5
o 第5节中定义的一个八位公钥算法ID
o a variable-length field containing KDF parameters, identical to the corresponding field in the ECDH public key, formatted as follows:
o 包含KDF参数的可变长度字段，与ECDH公钥中的相应字段相同，格式如下：
- a one-octet size of the following fields; values 0 and 0xff are reserved for future extensions
- 以下字段的一个八位字节大小；值0和0xff保留用于将来的扩展
- a one-octet value 01, reserved for future extensions
- 一个八位字节值01，保留用于将来的扩展
- a one-octet hash function ID used with the KDF
- 与KDF一起使用的一个八位组哈希函数ID
- a one-octet algorithm ID for the symmetric algorithm used to wrap the symmetric key for message encryption; see Section 8 for details
- 对称算法的一个八位组算法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 20个八位字节，表示字符串“匿名发送者”的UTF-8编码，即八位字节序列41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 72 20 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参数序列的大小为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]中描述了密钥包装方法。KDF生成一个对称密钥，该密钥用作[RFC3394]中指定的密钥加密密钥（KEK）。有关KEK算法选择的详细信息，请参阅第13节，KEK算法应为三种AES算法之一。使用默认初始值[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:
密钥包装方法的输入是从会话密钥派生的值“m”，如[RFC4880]第5.1节“公钥加密会话密钥包（标记1）”所述，但PKCS#1.5（公钥加密标准版本1.5）填充步骤被省略。使用[PKCS5]中描述的方法将结果填充到8字节粒度。例如，以下AES-256会话密钥（其中32个八位字节表示为从k0到k31）构成以下40个八位字节序列：
09 k0 k1 ... k31 c0 c1 05 05 05 05 05
09 k0 k1。。。k31 c0 c1 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:
该方法的输出由两个字段组成。第一个字段是包含用于建立共享密钥的临时密钥的MPI。第二个字段由以下两个字段组成：
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 一个八位字节，用于编码密钥包装方法结果的大小（以八位字节为单位）；值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 如上所述，最多254个八位字节表示密钥包装方法的结果，应用于8字节填充会话密钥
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).
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节“符号加密完整性保护数据包（标签18）”，修改检测码（MDC）必须在对称密钥受ECDH保护的任何时候使用。
The following algorithm-specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support ECDH and ECDSA.
[RFC4880]第5.5.2节“公钥数据包格式”中添加了以下特定于算法的数据包，以支持ECDH和ECDSA。
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
- 以下字段的一个八位字节大小；值0和0xFF保留用于将来的扩展
- octets representing a curve OID, defined in Section 11
- 表示曲线OID的八位字节，定义见第11节
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
- 以下字段的一个八位字节大小；值0和0xFF保留用于将来的扩展
- the octets representing a curve OID, defined in Section 11
- 表示曲线OID的八位字节，定义见第11节
- 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
- 以下字段的一个八位字节大小；值0和0xff保留用于将来的扩展
- a one-octet value 01, reserved for future extensions
- 一个八位字节值01，保留用于将来的扩展
- a one-octet hash function ID used with a KDF
- 与KDF一起使用的一个八位组哈希函数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
- 对称算法的一个八位组算法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节添加了以下特定于算法的数据包。[RFC4880]中的“密钥包格式”，以支持ECDH和ECDSA。
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 表示密钥的整数的MPI，该密钥是公共EC点的标量
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节“第3版签名包格式”定义了签名格式。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。以下两个字段是应用KDF的结果，如第8节所述。
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 一个八位组大小，后跟使用第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标识符len十六进制[FIPS-186-3]表示的曲线名称中的对象OID曲线OID字节
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.
第三列中的八位字节序列是将可分辨编码规则（DER）应用于ASN.1对象标识符并进行后续截断的结果。截断将删除编码对象标识符的两个字段。第一省略字段是表示对象标识符标签的一个八位字节，第二省略字段是对象标识符主体的长度。例如，NIST P-256曲线OID的完整ASN.1 DER编码为“06 08 2A 86 48 CE 3D 03 01 07”，通过省略前两个八位字节构成上表中的第一个条目。只有被截断的八位字节序列才是曲线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.
符合要求的应用程序必须实现NIST曲线P-256，可以实现NIST曲线P-384，并且应该实现第11节中定义的NIST曲线P-521。符合要求的应用程序必须实现SHA2-256，并应实现SHA2-384和SHA2-512。兼容的应用程序必须实现AES-128，并且应该实现AES-256。
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 256 128
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，以及其他允许的组合。
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.
与上表一致，下表定义了KDF哈希算法和AES KEK加密算法，该算法应与ECDH的给定曲线一起使用。对于给定的ECC曲线，可以使用更强的KDF哈希算法或AES KEK算法。
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
NIST曲线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.
本文件明确禁止将AES以外的算法用作KEK算法，因为ECDH格式的向后兼容性不受关注。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}，第二个收件人的集合是{B，A}，则交集是两个算法（A和B）的无序集合。在这种情况下，兼容应用程序应选择更强的加密算法。
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.
资源约束（例如有限的计算能力）是应用程序可能更喜欢使用最弱算法的一个可能原因。另一方面是可以实现本文档中定义的每个算法的应用程序。大多数应用程序预计可分为两类。第二类或最强类中的兼容应用程序应首选AES-256而不是AES-192。
SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
在ECDH方法中，SHA-1不得与ECDSA或KDF一起使用。
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密钥。符合要求的应用程序必须仅使用迭代和盐析S2K来保护私钥，如[RFC4880]第3.7.1.3节“迭代和盐析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格式的使用可以通过解密或签名oracle模型建模时（例如，当应用程序是向未经身份验证的远程用户执行解密的网络服务时），侧通道攻击是一个问题。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]创建的“相当好的隐私（PGP）”注册表的“公钥算法”范围（或[RFC5226]术语中的“名称空间”）分配了一个算法编号。根据第5节的定义，已经分配了两个ID号。第一个值19已指定用于ECDSA，当前未使用，而另一个值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消息格式”，RFC 48802007年11月。
[SuiteB] National Security Agency, "NSA Suite B Cryptography", March 11, 2010, http://www.nsa.gov/ia/programs/suiteb_cryptography/.
[SuiteB]国家安全局，“NSA套件B加密”，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特别出版物800-56A第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]美国商务部国家标准与技术研究所，“安全哈希标准（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. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.translate error, please retry
[PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based Cryptography Standard", March 25, 1999.
[PKCS5]RSA实验室，“PKCS#5 v2.0：基于密码的加密标准”，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，“在RFCs中编写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
[KOBLITZ]N.KOBLITZ，“数论与密码学课程”，第六章椭圆曲线，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，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", September 2000.
[SEC1]高效密码标准组，“SEC1：椭圆曲线密码术”，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