Internet Engineering Task Force (IETF) J. Herzog
Request for Comments: 6278 R. Khazan
Category: Informational MIT Lincoln Laboratory
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) J. Herzog
Request for Comments: 6278 R. Khazan
Category: Informational MIT Lincoln Laboratory
ISSN: 2070-1721 June 2011
Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax
静态椭圆曲线Diffie-Hellman密钥协商在密码消息语法中的应用
Abstract
摘要
This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates.
本文档描述了如何在加密消息语法中使用“静态椭圆曲线Diffie-Hellman密钥协商方案”（即椭圆曲线Diffie-Hellman，其中两个参与者都使用静态Diffie-Hellman值）。在这种形式的密钥协议中，发送方和接收方的Diffie-Hellman值都是证书中包含的长期值。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6278.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6278.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(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.
(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................5
2. EnvelopedData Using Static-Static ECDH ..........................5
2.1. Fields of the KeyAgreeRecipientInfo ........................5
2.2. Actions of the Sending Agent ...............................6
2.3. Actions of the Receiving Agent .............................7
3. AuthenticatedData Using Static-Static ECDH ......................8
3.1. Fields of the KeyAgreeRecipientInfo ........................8
3.2. Actions of the Sending Agent ...............................8
3.3. Actions of the Receiving Agent .............................9
4. AuthEnvelopedData Using Static-Static ECDH ......................9
4.1. Fields of the KeyAgreeRecipientInfo ........................9
4.2. Actions of the Sending Agent ...............................9
4.3. Actions of the Receiving Agent .............................9
5. Comparison to RFC 5753 ..........................................9
6. Requirements and Recommendations ...............................10
7. Security Considerations ........................................12
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................5
2. EnvelopedData Using Static-Static ECDH ..........................5
2.1. Fields of the KeyAgreeRecipientInfo ........................5
2.2. Actions of the Sending Agent ...............................6
2.3. Actions of the Receiving Agent .............................7
3. AuthenticatedData Using Static-Static ECDH ......................8
3.1. Fields of the KeyAgreeRecipientInfo ........................8
3.2. Actions of the Sending Agent ...............................8
3.3. Actions of the Receiving Agent .............................9
4. AuthEnvelopedData Using Static-Static ECDH ......................9
4.1. Fields of the KeyAgreeRecipientInfo ........................9
4.2. Actions of the Sending Agent ...............................9
4.3. Actions of the Receiving Agent .............................9
5. Comparison to RFC 5753 ..........................................9
6. Requirements and Recommendations ...............................10
7. Security Considerations ........................................12
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
This document describes how to use the static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman [RFC6090] where both participants use static Diffie-Hellman values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS is a standard notation and representation for cryptographic messages. The CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define
本文档描述了如何在加密消息语法（CMS）[RFC5652]中使用静态椭圆曲线Diffie-Hellman密钥协商方案（即椭圆曲线Diffie-Hellman[RFC6090]，其中两个参与者都使用静态Diffie-Hellman值）。CMS是加密消息的标准符号和表示形式。CMS使用ASN.1符号[X.680][X.681][X.682][X.683]来定义
a number of structures that carry both cryptographically protected information and key-management information regarding the keys used. Of particular interest here are three structures:
一系列结构，包含密码保护信息和有关所用密钥的密钥管理信息。这里特别有趣的是三种结构：
o EnvelopedData, which holds encrypted (but not necessarily authenticated) information [RFC5652],
o EnvelopedData，它保存加密（但不一定经过身份验证）信息[RFC5652]，
o AuthenticatedData, which holds authenticated (MACed) information [RFC5652], and
o AuthenticatedData，其中包含已验证（MACed）信息[RFC5652]，以及
o AuthEnvelopedData, which holds information protected by authenticated encryption: a cryptographic scheme that combines encryption and authentication [RFC5083].
o AuthEnvelopedData，它保存由经过身份验证的加密保护的信息：一种结合了加密和身份验证的加密方案[RFC5083]。
All three of these types share the same basic structure. First, a fresh symmetric key is generated. This symmetric key has a different name that reflects its usage in each of the three structures. EnvelopedData uses a content-encryption key (CEK); AuthenticatedData uses an authentication key; AuthEnvelopedData uses a content-authenticated-encryption key. The originator uses the symmetric key to cryptographically protect the content. The symmetric key is then wrapped for each recipient; only the intended recipient has access to the private keying material necessary to unwrap the symmetric key. Once unwrapped, the recipient uses the symmetric key to decrypt the content, check the authenticity of the content, or both. The CMS supports several different approaches to symmetric key wrapping, including:
这三种类型都具有相同的基本结构。首先，生成一个新的对称密钥。此对称密钥具有不同的名称，以反映其在三种结构中的用法。EnvelopedData使用内容加密密钥（CEK）；AuthenticatedData使用身份验证密钥；AuthEnvelopedData使用经过内容验证的加密密钥。发起人使用对称密钥对内容进行加密保护。然后为每个接收者包装对称密钥；只有预期的接收者才能访问打开对称密钥所需的私钥材料。打开包装后，收件人使用对称密钥对内容进行解密，检查内容的真实性，或者两者兼而有之。CMS支持几种不同的对称密钥包装方法，包括：
o key transport: the symmetric key is encrypted using the public encryption key of some recipient,
o 密钥传输：对称密钥使用某个收件人的公共加密密钥进行加密，
o key-encryption key: the symmetric key is encrypted using a previously distributed symmetric key, and
o 密钥加密密钥：使用先前分发的对称密钥对对称密钥进行加密，并且
o key agreement: the symmetric key is encrypted using a key-encryption key (KEK) created using a key-agreement scheme and a key-derivation function (KDF).
o 密钥协商：使用密钥协商方案和密钥派生函数（KDF）创建的密钥加密密钥（KEK）对对称密钥进行加密。
One such key-agreement scheme is the Diffie-Hellman algorithm [RFC2631], which uses group theory to produce a value known only to its two participants. In this case, the participants are the originator and one of the recipients. Each participant produces a private value and a public value, and each participant can produce the shared secret value from their own private value and their counterpart's public value. There are some variations on the basic algorithm:
一个这样的密钥协商方案是Diffie-Hellman算法[RFC2631]，它使用群论产生一个只有两个参与者知道的值。在这种情况下，参与者是发起人和接收人之一。每个参与者产生一个私人价值和一个公共价值，每个参与者可以从自己的私人价值和对方的公共价值中产生共享的秘密价值。基本算法有一些变化：
o The basic algorithm typically uses the group 'Z mod p', meaning the set of integers modulo some prime p. One can also use an elliptic curve group, which allows for shorter messages.
o 基本算法通常使用组'Z mod p'，这意味着模某些素数p的整数集。还可以使用椭圆曲线组，它允许发送较短的消息。
o Over elliptic curve groups, the standard algorithm can be extended to incorporate the 'cofactor' of the group. This method, called 'cofactor Elliptic Curve Diffie-Hellman' [SP800-56A] can prevent certain attacks possible in the elliptic curve group.
o 在椭圆曲线群上，标准算法可以扩展为包含群的“余因子”。这种称为“余因子椭圆曲线Diffie-Hellman”[SP800-56A]的方法可以防止椭圆曲线组中可能发生的某些攻击。
o The participants can generate fresh new public/private values (called ephemeral values) for each run of the algorithm, or they can re-use long-term values (called static values). Ephemeral values add randomness to the resulting private value, while static values can be embedded in certificates. The two participants do not need to use the same kind of value: either participant can use either type. In 'ephemeral-static' Diffie-Hellman, for example, the sender uses an ephemeral public/private pair value while the receiver uses a static pair. In 'static-static' Diffie-Hellman, on the other hand, both participants use static pairs. (Receivers cannot use ephemeral values in this setting, and so we ignore ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this document.)
o 参与者可以为算法的每次运行生成新的公共/私有值（称为临时值），也可以重用长期值（称为静态值）。临时值为生成的私有值添加了随机性，而静态值可以嵌入到证书中。两个参与者不需要使用相同类型的值：任何一个参与者都可以使用任何一种类型。例如，在“临时静态”Diffie Hellman中，发送方使用临时公共/私有对值，而接收方使用静态对。另一方面，在“静态-静态”Diffie-Hellman中，两个参与者都使用静态对。（接收器在此设置中不能使用临时值，因此我们在本文档中忽略临时值和静态临时值Diffie Hellman。）
Several of these variations are already described in existing CMS standards; for example, [RFC3370] contains the conventions for using ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z mod p) group. [RFC5753] contains the conventions for using ephemeral-static Diffie-Hellman over elliptic curves (both standard and cofactor methods). It does not, however, contain conventions for using either method of static-static Elliptic Curve Diffie-Hellman, preferring to discuss the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) algorithm instead.
现有CMS标准中已经描述了其中的几个变化；例如，[RFC3370]包含在“基本”（Z mod p）组上使用瞬时静态和静态Diffie Hellman的约定。[RFC5753]包含在椭圆曲线上使用短暂静态Diffie-Hellman的约定（标准方法和辅因子方法）。然而，它不包含使用静态椭圆曲线Diffie-Hellman任一方法的约定，而是更倾向于讨论椭圆曲线Menezes-Qu-Vanstone（ECMQV）算法。
In this document, we specify the conventions for using static-static Elliptic Curve Diffie-Hellman (ECDH) for both standard and cofactor methods. Our motivation stems from the fact that ECMQV has been removed from the National Security Agency's Suite B of cryptographic algorithms and will therefore be unavailable to some participants. These participants can use ephemeral-static Elliptic Curve Diffie-Hellman, of course, but ephemeral-static Diffie-Hellman does not provide source authentication. The CMS does allow the application of digital signatures for source authentication, but this alternative is available only to those participants with certified signature keys. By specifying conventions for static-static Elliptic Curve Diffie-Hellman in this document, we present a third alternative for source authentication, available to those participants with certified Elliptic Curve Diffie-Hellman keys.
在本文档中，我们为标准方法和辅助因子方法指定了使用静态椭圆曲线Diffie-Hellman（ECDH）的约定。我们的动机源于这样一个事实：ECMQV已从国家安全局的加密算法套件B中删除，因此一些参与者将无法使用。当然，这些参与者可以使用临时静态椭圆曲线Diffie-Hellman，但临时静态Diffie-Hellman不提供源身份验证。CMS确实允许应用数字签名进行源身份验证，但此替代方案仅适用于具有认证签名密钥的参与者。通过在本文中指定静态椭圆曲线Diffie-Hellman的约定，我们为源身份验证提供了第三种备选方案，可供具有认证椭圆曲线Diffie-Hellman密钥的参与者使用。
We note that like ephemeral-static ECDH, static-static ECDH creates a secret key shared by the sender and receiver. Unlike ephemeral-static ECDH, however, static-static ECDH uses a static key pair for the sender. Each of the three CMS structures discussed in this document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses static-static ECDH to achieve different goals:
我们注意到，与短暂的静态ECDH一样，静态ECDH创建了一个由发送方和接收方共享的密钥。然而，与短暂的静态ECDH不同，静态ECDH为发送方使用静态密钥对。本文档中讨论的三种CMS结构（EnvelopedData、AuthenticatedData和AuthEnvelopedData）都使用静态ECDH来实现不同的目标：
o EnvelopedData uses static-static ECDH to provide data confidentiality. It will not necessarily, however, provide data authenticity.
o EnvelopedData使用静态ECDH提供数据机密性。但是，它不一定提供数据真实性。
o AuthenticatedData uses static-static ECDH to provide data authenticity. It will not provide data confidentiality.
o AuthenticatedData使用静态ECDH提供数据真实性。它不会提供数据保密性。
o AuthEnvelopedData uses static-static ECDH to provide both confidentiality and data authenticity.
o AuthEnvelopedData使用静态ECDH提供机密性和数据真实性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
If an implementation uses static-static ECDH with the CMS EnvelopedData, then the following techniques and formats MUST be used. The fields of EnvelopedData are as in [RFC5652]; as static-static ECDH is a key-agreement algorithm, the RecipientInfo 'kari' choice is used. When using static-static ECDH, the EnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key.
如果实现使用静态ECDH和CMS EnvelopedData，则必须使用以下技术和格式。信封数据字段如[RFC5652]所示；由于静态ECDH是一种密钥协商算法，因此使用RecipientInfo“kari”选项。当使用静态ECDH时，EnvelopedData originatorInfo字段可能包括用于形成成对密钥的EC公钥的证书。
When using static-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo [RFC5652] are as follows:
将静态ECDH与EnvelopedData一起使用时，KeyAgreeRecipientInfo[RFC5652]的字段如下所示：
o version MUST be 3.
o 版本必须为3。
o originator identifies the static EC public key of the sender. It MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and it MUST point to one of the sending agent's certificates.
o 发起者识别发送者的静态EC公钥。它必须是issuerAndSerialNumber或subjectKeyIdentifier，并且必须指向发送代理的证书之一。
o ukm MAY be present or absent. However, message originators SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. As specified in [RFC5652], implementations MUST support ukm message recipient processing, so
o ukm可能出席或缺席。但是，消息发起人应包括ukm，并应确保ukm的值对于所发送的消息是唯一的。如[RFC5652]所述，实现必须支持ukm消息收件人处理，因此
interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. The ukm, if present, is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure [RFC5753] and therefore used as an input to the key-derivation function.
如果存在或不存在ukm，则互操作性不是问题。对ukm使用新值将确保为同一发送方和接收方之间的每条消息生成不同的密钥。ukm（如果存在）位于ECC CMS SharedInfo结构[RFC5753]的EntityUIInfo字段中，因此用作密钥派生函数的输入。
o keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm, which in this case is a key-agreement algorithm (see Section 5). The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm identifier that indicates the symmetric encryption algorithm used to encrypt the content-encryption key (CEK) with the key-encryption key (KEK) and any associated parameters (see Section 5).
o keyEncryptionAlgorithm必须包含密钥加密算法的对象标识符，在本例中，该算法是密钥协商算法（请参见第5节）。参数字段包含KeyWrapAlgorithm。KeyWrapAlgorithm是一种算法标识符，表示用于使用密钥加密密钥（KEK）和任何相关参数加密内容加密密钥（CEK）的对称加密算法（见第5节）。
o recipientEncryptedKeys contains an identifier and an encrypted CEK for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the static-static ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
o recipientEncryptedKeys包含每个收件人的标识符和加密CEK。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态ECDH公钥。RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgorithm指定的算法使用静态ECDH生成的成对密钥加密密钥加密的内容加密密钥。
When using static-static ECDH with EnvelopedData, the sending agent first obtains the EC public key(s) and domain parameters contained in the recipient's certificate. It MUST confirm the following at least once per recipient-certificate:
当将静态ECDH与EnvelopedData一起使用时，发送代理首先获取接收方证书中包含的EC公钥和域参数。每个收件人证书必须至少确认一次以下内容：
o that both certificates (the recipient's certificate and its own) contain public-key values with the same curve parameters, and
o 两个证书（收件人的证书及其自己的证书）都包含具有相同曲线参数的公钥值，以及
o that both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm identifiers id-ecPublicKey or id-ecDH [RFC5480]).
o 将这两个公钥值标记为适合ECDH（即，用算法标识符id ecPublicKey或id ECDH[RFC5480]标记）。
The sender then determines whether to use standard or cofactor Diffie-Hellman. After doing so, the sender then determines which hash algorithms to use for the key-derivation function. It then chooses the keyEncryptionAlgorithm value that reflects these choices. It then determines:
然后，发送方确定是使用标准还是辅因子Diffie Hellman。执行此操作后，发送方然后确定要用于密钥派生函数的哈希算法。然后选择反映这些选择的keyEncryptionAlgorithm值。然后确定：
o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key size in bits, and
o 一个整数“keydatalen”，它是KeyWrapAlgorithm对称密钥大小（以位为单位），以及
o the value of ukm, if used.
o ukm的值（如果使用）。
The sender then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The sending agent then performs either the Elliptic Curve Diffie-Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The sending agent then applies the simple hash-function construct of [X963] (using the hash algorithm identified in the key-agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the sending agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key (KEK) to wrap the CEK for that recipient, as specified in [RFC5652].
然后，发送方确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（参见[RFC5753]第7.2节）。然后，发送代理执行[RFC6090]的椭圆曲线Diffie-Hellman操作（对于标准Diffie-Hellman）或[SP800-56A]的椭圆曲线密码辅因子Diffie-Hellman（ECC CDH）原语（对于辅因子Diffie-Hellman）。然后，发送代理将[X963]的简单散列函数构造（使用密钥协商算法中标识的散列算法）应用于Diffie-Hellman操作和SharedInfo字符串的结果。（该构造也在[SEC1]的第3.6.1节中进行了描述。）因此，发送代理获得一个共享秘密位字符串“K”，该字符串用作成对密钥加密密钥（KEK），以按照[RFC5652]中的规定包装该接收方的CEK。
When using static-static ECDH with EnvelopedData, the receiving agent retrieves keyEncryptionAlgorithm to determine the key-agreement algorithm chosen by the sender, which will identify:
当使用带有EnvelopedData的静态ECDH时，接收代理检索keyEncryptionAlgorithm以确定发送方选择的密钥协商算法，该算法将识别：
o the domain parameters of the curve used,
o 所用曲线的域参数，
o whether standard or cofactor Diffie-Hellman was used, and
o 是否使用标准或辅助因子Diffie Hellman，以及
o which hash function was used for the KDF.
o KDF使用了哪个哈希函数。
The receiver then retrieves the sender's certificate identified in the rid field and extracts the EC public key(s) and domain parameters contained therein. It MUST confirm the following at least once per sender certificate:
然后，接收方检索rid字段中标识的发送方证书，并提取其中包含的EC公钥和域参数。每个发件人证书必须至少确认一次以下内容：
o that both certificates (the sender's certificate and its own) contain public-key values with the same curve parameters, and
o 两个证书（发送方的证书及其自己的证书）都包含具有相同曲线参数的公钥值，以及
o that both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm identifiers id-ecPublicKey or id-ecDH [RFC5480]).
o 将这两个公钥值标记为适合ECDH（即，用算法标识符id ecPublicKey或id ECDH[RFC5480]标记）。
The receiver then determines whether standard or cofactor Diffie-Hellman was used. The receiver then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The receiving agent then performs either the Elliptic Curve Diffie-Hellman operation of [RFC6090] (for
然后，接收器确定是否使用标准或辅因子Diffie Hellman。然后，接收器确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（参见[RFC5753]第7.2节）。然后，接收代理执行[RFC6090]的椭圆曲线Diffie-Hellman操作（用于
standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The receiving agent then applies the simple hash-function construct of [X963] (using the hash algorithm identified in the key-agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the receiving agent obtains a shared secret bit string "K", which it uses as the pairwise key-encryption key to unwrap the CEK.
标准Diffie-Hellman）或[SP800-56A]的椭圆曲线密码辅因子Diffie-Hellman（ECC CDH）原语（用于辅因子Diffie-Hellman）。然后，接收代理将[X963]的简单散列函数构造（使用密钥协商算法中标识的散列算法）应用于Diffie-Hellman操作和SharedInfo字符串的结果。（该构造也在[SEC1]的第3.6.1节中进行了描述。）因此，接收代理获得一个共享秘密比特串“K”，它使用该比特串作为成对密钥加密密钥来打开CEK。
This section describes how to use the static-static ECDH key-agreement algorithm with AuthenticatedData. When using static-static ECDH with AuthenticatedData, the fields of AuthenticatedData are as in [RFC5652], but with the following restrictions:
本节介绍如何对AuthenticatedData使用静态ECDH密钥协商算法。对AuthenticatedData使用静态ECDH时，AuthenticatedData字段如[RFC5652]所示，但有以下限制：
o macAlgorithm MUST contain the algorithm identifier of the message authentication code (MAC) algorithm. This algorithm SHOULD be one of the following -- id-hmacWITHSHA224, id-hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512 -- and SHOULD NOT be hmac-SHA1. (See Section 5.)
o macAlgorithm必须包含消息身份验证码（MAC）算法的算法标识符。此算法应为以下算法之一——id-hmacWITHSHA224、id-hmacWITHSHA256、id-hmacWITHSHA384或id-hmacWITHSHA512——且不应为hmac-SHA1。（见第5节。）
o digestAlgorithm MUST contain the algorithm identifier of the hash algorithm. This algorithm SHOULD be one of the following -- id-sha224, id-sha256, id-sha384, or id-sha512 -- and SHOULD NOT be id-sha1. (See Section 5.)
o digestAlgorithm必须包含哈希算法的算法标识符。此算法应该是以下算法之一——id-sha224、id-sha256、id-sha384或id-sha512——而不应该是id-sha1。（见第5节。）
As static-static ECDH is a key-agreement algorithm, the RecipientInfo kari choice is used in the AuthenticatedData. When using static-static ECDH, the AuthenticatedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key.
由于静态ECDH是一种密钥协商算法，因此在认证数据中使用RecipientInfo-kari选项。当使用静态ECDH时，AuthenticatedData originatorInfo字段可包括用于形成成对密钥的EC公钥的证书。
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The authentication key is wrapped in the same manner as is described there for the content-encryption key.
AuthenticatedData KeyAgreentRecipientInfo字段的使用方式与本文件第2.1节中相应EnvelopedData KeyAgreentRecipientInfo字段的使用方式相同。身份验证密钥的包装方式与内容加密密钥的包装方式相同。
The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document.
按照本文件第2.2节的规定，发送代理使用与具有静态ECDH的EnvelopedData相同的操作。
The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document.
按照本文件第2.3节的规定，接收代理使用与具有静态ECDH的信封数据相同的操作。
When using static-static ECDH with AuthEnvelopedData, the fields of AuthEnvelopedData are as in [RFC5083]. As static-static ECDH is a key-agreement algorithm, the RecipientInfo kari choice is used. When using static-static ECDH, the AuthEnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key used in the formation of the pairwise key.
将静态ECDH与AuthEnvelopedData一起使用时，AuthEnvelopedData的字段如[RFC5083]所示。由于静态ECDH是一种密钥协商算法，因此使用RecipientInfo-kari选项。当使用静态ECDH时，AuthEnvelopedData originatorInfo字段可能包括用于形成成对密钥的EC公钥的证书。
The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The content-authenticated-encryption key is wrapped in the same manner as is described there for the content-encryption key.
AuthEnvelopedData KeyAgreeRecipientInfo字段的使用方式与本文档第2.1节中相应EnvelopedData KeyAgreeRecipientInfo字段的使用方式相同。内容认证加密密钥的包装方式与内容加密密钥的包装方式相同。
The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document.
按照本文件第2.2节的规定，发送代理使用与具有静态ECDH的EnvelopedData相同的操作。
The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document.
按照本文件第2.3节的规定，接收代理使用与具有静态ECDH的信封数据相同的操作。
This document defines the use of static-static ECDH for EnvelopedData, AuthenticatedData, and AuthEnvelopedData. [RFC5753] defines ephemeral-static ECDH for EnvelopedData only.
本文档定义了对EnvelopedData、AuthenticatedData和AuthEnvelopedData使用静态ECDH。[RFC5753]仅为信封数据定义临时静态ECDH。
With regard to EnvelopedData, this document and [RFC5753] greatly parallel each other. Both specify how to apply Elliptic Curve Diffie-Hellman and differ only on how the sender's public value is to be communicated to the recipient. In [RFC5753], the sender provides the public value explicitly by including an OriginatorPublicKey value in the originator field of KeyAgreeRecipientInfo. In this document, the sender includes a reference to a (certified) public value by including either an IssuerAndSerialNumber or SubjectKeyIdentifier value in the same field. Put another way, [RFC5753] provides an interpretation of a KeyAgreeRecipientInfo structure where:
关于EnvelopedData，本文件与[RFC5753]非常相似。两者都指定了如何应用椭圆曲线Diffie-Hellman，不同之处仅在于如何将发送者的公共价值传达给接收者。在[RFC5753]中，发送方通过在KeyAgreeRecipientInfo的“发起者”字段中包含OriginatorPublicKey值来显式提供公共值。在本文档中，发送方通过在同一字段中包含IssuerAndSerialNumber或SubjectKeyIdentifier值来引用（认证的）公共值。换句话说，[RFC5753]提供了KeyAgreeRecipientInfo结构的解释，其中：
o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie-Hellman, and
o keyEncryptionAlgorithm值表示椭圆曲线Diffie-Hellman，以及
o the originator field contains an OriginatorPublicKey value.
o “原始发件人”字段包含原始发件人PublicKey值。
This document, on the other hand, provides an interpretation of a KeyAgreeRecipientInfo structure where:
另一方面，本文档提供了KeyAgreeRecipientInfo结构的解释，其中：
o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie-Hellman, and
o keyEncryptionAlgorithm值表示椭圆曲线Diffie-Hellman，以及
o the originator field contains either an IssuerAndSerialNumber value or a SubjectKeyIdentifier value.
o “发起人”字段包含IssuerAndSerialNumber值或SubjectKeyIdentifier值。
AuthenticatedData or AuthEnvelopedData messages, on the other hand, are not given any form of ECDH by [RFC5753]. This is appropriate: that document only defines ephemeral-static Diffie-Hellman, and this form of Diffie-Hellman does not (inherently) provide any form of data authentication or data-origin authentication. This document, on the other hand, requires that the sender use a certified public value. Thus, this form of key agreement provides implicit key authentication and, under some limited circumstances, data-origin authentication. (See Section 7.)
另一方面，[RFC5753]未向AuthenticatedData或AuthEnvelopedData消息提供任何形式的ECDH。这是合适的：该文档只定义了短暂的静态Diffie-Hellman，而这种形式的Diffie-Hellman（本质上）不提供任何形式的数据身份验证或数据源身份验证。另一方面，此文档要求发件人使用经认证的公共值。因此，这种形式的密钥协议提供隐式密钥身份验证，在某些有限的情况下，还提供数据源身份验证。（见第7节。）
This document does not define any new ASN.1 structures or algorithm identifiers. It provides new ways to interpret structures from [RFC5652] and [RFC5753], and it allows previously defined algorithms to be used under these new interpretations. Specifically:
本文档未定义任何新的ASN.1结构或算法标识符。它提供了解释[RFC5652]和[RFC5753]结构的新方法，并允许在这些新解释下使用先前定义的算法。明确地：
o The ECDH key-agreement algorithm identifiers from [RFC5753] define only how Diffie-Hellman values are processed, and not where these values are created. Therefore, they can be used for static-static ECDH with no changes.
o [RFC5753]中的ECDH密钥协商算法标识符仅定义Diffie-Hellman值的处理方式，而不是这些值的创建位置。因此，它们可用于静态ECDH，无任何变化。
o The key-wrap, MAC, and digest algorithms referenced in [RFC5753] describe how the secret key is to be used but not created. Therefore, they can be used with keys from static-static ECDH without modification.
o [RFC5753]中引用的密钥换行、MAC和摘要算法描述了如何使用但不创建密钥。因此，它们可以与静态ECDH的键一起使用，无需修改。
It is RECOMMENDED that implementations of this specification support AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData is OPTIONAL.
建议本规范的实现支持AuthenticatedData和EnvelopedData。对AuthEnvelopedData的支持是可选的。
Implementations that support this specification MUST support standard Elliptic Curve Diffie-Hellman, and these implementations MAY also support cofactor Elliptic Curve Diffie-Hellman.
支持此规范的实现必须支持标准的椭圆曲线Diffie-Hellman，并且这些实现还可以支持辅因子椭圆曲线Diffie-Hellman。
In order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by [RFC5480].
为了鼓励互操作性，实现应该使用[RFC5480]指定的椭圆曲线域参数。
Implementations that support standard static-static Elliptic Curve Diffie-Hellman:
支持标准静态椭圆曲线Diffie-Hellman的实现：
o MUST support the dhSinglePass-stdDH-sha256kdf-scheme key-agreement algorithm;
o 必须支持dhSinglePass-stdDH-sha256kdf-scheme密钥协商算法；
o MAY support the dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme, and dhSinglePass-stdDH-sha512kdf-scheme key-agreement algorithms; and
o 可支持dhSinglePass-stdDH-sha224kdf-scheme、dhSinglePass-stdDH-sha384kdf-scheme、dhSinglePass-stdDH-sha512kdf-scheme密钥协商算法；和
o SHOULD NOT support the dhSinglePass-stdDH-sha1kdf-scheme algorithm.
o 不应支持dhSinglePass-stdDH-sha1kdf-scheme算法。
Other algorithms MAY also be supported.
也可以支持其他算法。
Implementations that support cofactor static-static Elliptic Curve Diffie-Hellman:
支持辅因子静态椭圆曲线Diffie-Hellman的实现：
o MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key-agreement algorithm;
o 必须支持dhSinglePass-cofactorDH-sha256kdf-scheme密钥协商算法；
o MAY support the dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH-sha512kdf-scheme key-agreement algorithms; and
o 可支持dhSinglePass-cofactorDH-sha224kdf-scheme、dhSinglePass-cofactorDH-sha384kdf-scheme、dhSinglePass-cofactorDH-sha512kdf-scheme密钥协商算法；和
o SHOULD NOT support the dhSinglePass-cofactorDH-sha1kdf-scheme algorithm.
o 不应支持dhSinglePass-cofactorDH-sha1kdf-scheme算法。
In addition, all implementations:
此外，所有实现：
o MUST support the id-aes128-wrap key-wrap algorithm and the id-aes128-cbc content-encryption algorithm;
o 必须支持id-aes128-wrap密钥包裹算法和id-aes128-cbc内容加密算法；
o MAY support:
o 可支持：
* the id-aes192-wrap and id-aes256-wrap key-wrap algorithms;
* id-aes192-wrap和id-aes256-wrap密钥包裹算法；
* the id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, id-aes128-GCM, id-aes192-GCM, and id-aes256-GCM authenticated-encryption algorithms; and
* id-aes128-CCM、id-aes192-CCM、id-aes256-CCM、id-aes128-GCM、id-aes192-GCM和id-aes256-GCM认证加密算法；和
* the id-aes192-cbc and id-aes256-cbc content-encryption algorithms.
* id-aes192-cbc和id-aes256-cbc内容加密算法。
o SHOULD NOT support the id-alg-CMS3DESwrap key-wrap algorithm or the des-ede3-cbc content-encryption algorithms.
o 不应支持id-alg-CMS3DESwrap密钥包裹算法或des-ede3-cbc内容加密算法。
(All algorithms above are defined in [RFC3370], [RFC3565], [RFC5084], and [RFC5753].) Unless otherwise noted above, other algorithms MAY also be supported.
（以上所有算法均在[RFC3370]、[RFC3565]、[RFC5084]和[RFC5753]中定义。）除非上文另有说明，否则也可以支持其他算法。
All security considerations in Section 9 of [RFC5753] apply.
[RFC5753]第9节中的所有安全注意事项均适用。
Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in the ukm. As described in [RFC5753], the ukm value (if present) will be embedded in an ECC-CMS-SharedInfo structure, and the DER encoding of this structure will be used as the 'SharedInfo' input to the key-derivation function of [X963]. The purpose of this input is to add a message-unique value to the key-distribution function so that two different sessions of static-static ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is re-used, on the other hand, then the ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will re-use the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks).
在ukm中使用静态Diffie-Hellman（标准或辅因子）而不使用某些每条消息值时，必须格外小心。如[RFC5753]中所述，ukm值（如果存在）将嵌入ECC CMS SharedInfo结构中，该结构的DER编码将用作[X963]密钥派生函数的“SharedInfo”输入。此输入的目的是向密钥分发函数添加消息唯一值，以便给定代理对之间的静态ECDH的两个不同会话产生独立密钥。另一方面，如果未使用或重复使用ukm值，则ECC CMS SharedInfo结构（和“SharedInfo”输入）可能不会因消息而异。在这种情况下，两个代理将在多条消息中重复使用相同的键控材料。这被认为是不好的加密实践，可能会使发送方遭受Diffie-Hellman攻击（例如，“小子组”攻击[MenezesUstaoglu]或其他尚未发现的攻击）。
It is for these reasons that Section 2.1 states that message senders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of the ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used by the key-wrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications that cannot tolerate the inclusion of per-message information in the ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value.
正是由于这些原因，第2.1节规定，消息发送方应包括ukm，并应确保ukm的值对于所发送的消息是唯一的。确保ukm唯一性的一种方法是，消息发送者为每条消息选择一个“足够长”的随机字符串（其中，根据经验，“足够长”的字符串至少是KeyAgreentRecipientInfo结构的keyEncryptionAlgorithm字段中标识的密钥包裹算法使用的密钥的长度）。但是，也可以使用其他方法（如计数器）。此外，不能容忍在ukm中包含每条消息信息的应用程序（例如，由于带宽要求）不应在不确定接收者知道与其认证的Diffie-Hellman值相关联的私有值的情况下为接收者使用静态ECDH。
Static-static Diffie-Hellman, when used as described in this document, does not necessarily provide data-origin authentication. Consider, for example, the following sequence of events:
静态Diffie-Hellman，如本文档所述使用时，不一定提供数据源身份验证。例如，考虑以下事件序列：
o Alice sends an AuthEnvelopedData message to both Bob and Mallory. Furthermore, Alice uses a static-static DH method to transport the content-authenticated-encryption key to Bob, and some arbitrary method to transport the same key to Mallory.
o Alice向Bob和Mallory发送AuthEnvelopedData消息。此外，Alice使用静态DH方法将内容认证的加密密钥传输给Bob，并使用任意方法将相同的密钥传输给Mallory。
o Mallory intercepts the message and prevents Bob from receiving it.
o 马洛里截取消息并阻止鲍勃接收。
o Mallory recovers the content-authenticated-encryption key from the message received from Alice. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated-encryption algorithm and the same content-authenticated-encryption key used by Alice.
o Mallory从从Alice收到的消息中恢复经过内容验证的加密密钥。然后，Mallory创建她选择的新明文，并使用Alice使用的相同身份验证加密算法和相同内容验证加密密钥对其进行加密。
o Mallory then replaces the EncryptedContentInfo and MessageAuthenticationCode fields of Alice's message with the values Mallory just generated. She may additionally remove her RecipientInfo value from Alice's message.
o 然后，Mallory用Mallory刚刚生成的值替换Alice消息的EncryptedContentInfo和MessageAuthenticationCode字段。她还可以从Alice的邮件中删除RecipientInfo值。
o Mallory sends the modified message to Bob.
o Mallory将修改后的消息发送给Bob。
o Bob receives the message, validates the static-static DH values, and decrypts/authenticates the message.
o Bob接收消息，验证静态DH值，并解密/验证消息。
At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Mallory may not even be an apparent receiver of the modified message. Thus, this use of static-static Diffie-Hellman does not necessarily provide data-origin authentication. (We note that this example does not also contradict either confidentiality or data authentication: Alice's message was not received by anyone not intended by Alice, and Mallory's message was not modified before reaching Bob.)
此时，Bob已接收并验证了一条消息，该消息似乎是由Alice发送的，但其内容是由Mallory选择的。马洛里甚至可能不是修改过的消息的明显接收者。因此，静态Diffie-Hellman的这种使用不一定提供数据源身份验证。（我们注意到，该示例也不违反保密性或数据验证：Alice的消息未被Alice无意中接收到，Mallory的消息在到达Bob之前未被修改。）
More generally, the data origin may not be authenticated unless:
更一般地说，数据源可能无法验证，除非：
o it is a priori guaranteed that the message in question was sent to exactly one recipient, or
o 这是一种先验保证，即所讨论的邮件只发送给一个收件人，或者
o data-origin authentication is provided by some other mechanism (such as digital signatures).
o 数据源身份验证由其他一些机制（如数字签名）提供。
However, we also note that this lack of authentication is not a product of static-static ECDH per se, but is inherent in the way key-agreement schemes are used in the AuthenticatedData and AuthEnvelopedData structures of the CMS.
然而，我们也注意到，这种缺乏认证的情况并非静态ECDH本身的产物，而是CMS的AuthenticatedData和AuthenveledData结构中使用密钥协商方案的固有方式。
When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central
当双方使用本文档中所述的静态ECDH进行通信时，并且任一方的非对称密钥都是集中生成的，则该方的中心密钥是可能的
infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption by the sender's infrastructure would not be possible (though it would remain possible for the infrastructure of any recipient).
解密通信的基础设施（例如，用于应用层网络监视或过滤）。相比之下：如果改用短暂的静态ECDH，则发送方的基础设施将不可能进行此类解密（尽管对任何接收方的基础设施来说仍然是可能的）。
This work is sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government.
这项工作由美国空军根据空军合同FA8721-05-C-0002赞助。意见、解释、结论和建议均为作者的意见、解释、结论和建议，不一定得到美国政府的认可。
The authors would like to thank Jim Schaad, Russ Housley, Sean Turner, Brian Weis, Rene Struik, Brian Carpenter, David McGrew, and Stephen Farrell for their helpful comments and suggestions. We would also like to thank Jim Schaad for describing to us the attack described in Section 7.
作者要感谢Jim Schaad、Russ Housley、Sean Turner、Brian Weis、Rene Struik、Brian Carpenter、David McGrew和Stephen Farrell提供的有用意见和建议。我们还要感谢Jim Schaad向我们描述了第7节中描述的攻击。
[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月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[RFC3565]Schaad，J.，“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[RFC5084]Housley，R.，“在加密消息语法（CMS）中使用AES-CCM和AES-GCM认证加密”，RFC 5084，2007年11月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
[RFC5753]Turner，S.和D.Brown，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 5753，2010年1月。
[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月。
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication (SP) 800-56A, March 2007.
[SP800-56A]Barker，E.，Johnson，D.，和M.Smid，“使用离散对数加密的成对密钥建立方案的建议（修订版）”，NIST特别出版物（SP）800-56A，2007年3月。
[X963] "Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, 2001.
[X963]“金融服务业的公钥加密，使用椭圆曲线加密的密钥协议和密钥传输”，ANSI X9.632001。
[MenezesUstaoglu] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols", International Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154- 158, 2010.
[MenezesUstaoglu]Menezes，A.和B.Ustaoglu，“关于在Diffie-Hellman密钥协议协议中重用临时密钥”，国际应用密码学杂志，第2卷，第2期，第154-158页，2010年。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009.
[SEC1]高效密码组（SECG）标准，“第1节：椭圆曲线密码术”，版本2.0，2009年5月。
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation One: Specification of Basic Notation", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
[X.680]ITU-T，“信息技术——抽象语法符号一：基本符号规范”，建议X.680，ISO/IEC 8824-1:2002，2002年。
[X.681] ITU-T, "Information Technology - Abstract Syntax Notation One: Information Object Specification", Recommendation X.681, ISO/IEC 8824-2:2002, 2002.
[X.681]ITU-T，“信息技术-抽象语法符号1：信息对象规范”，建议X.681，ISO/IEC 8824-2:2002，2002年。
[X.682] ITU-T, "Information Technology - Abstract Syntax Notation One: Constraint Specification", Recommendation X.682, ISO/ IEC 8824-3:2002, 2002.
[X.682]ITU-T，“信息技术-抽象语法符号1：约束规范”，建议X.682，ISO/IEC 8824-3:2002，2002年。
[X.683] ITU-T, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", Recommendation X.683, ISO/IEC 8824-4:2002, 2002.
[X.683]ITU-T，“信息技术——抽象语法符号1：ASN.1规范的参数化”，建议X.683，ISO/IEC 8824-4:2002，2002年。
Authors' Addresses
作者地址
Jonathan C. Herzog MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA
Jonathan C.Herzog麻省理工学院林肯实验室244 Wood St.Lexington，马萨诸塞州02144
EMail: jherzog@ll.mit.edu
EMail: jherzog@ll.mit.edu
Roger Khazan MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA
罗杰·卡赞麻省理工学院林肯实验室美国马萨诸塞州莱克星顿伍德街244号，邮编：02144
EMail: rkh@ll.mit.edu
EMail: rkh@ll.mit.edu