Network Working Group E. Rescorla
Request for Comments: 2631 RTFM Inc.
Category: Standards Track June 1999
Network Working Group E. Rescorla
Request for Comments: 2631 RTFM Inc.
Category: Standards Track June 1999
Diffie-Hellman Key Agreement Method
Diffie-Hellman密钥协商方法
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.
本文件根据ANSI X9F1工作组制定的ANSI X9.42草案，标准化了一种特殊的Diffie-Hellman变体。Diffie-Hellman是一种密钥协商算法，用于双方就共享秘密达成一致。提供了一种将共享秘密转换为任意数量的密钥材料的算法。生成的密钥材料用作对称加密密钥。描述的Diffie-Hellman变体要求接收者拥有证书，但发起者可能拥有静态密钥对（公钥放置在证书中）或临时密钥对。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2
2. Overview Of Method . . . . . . . . . . . . . . . . . . . . 2
2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 2
2.1.1. Generation of ZZ . . . . . . . . . . . . . . . . . . . 3
2.1.2. Generation of Keying Material . . . . . . . . . . . . . 3
2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Keylengths for common algorithms . . . . . . . . . . . 5
2.1.5. Public Key Validation . . . . . . . . . . . . . . . . . 5
2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Key and Parameter Requirements . . . . . . . . . . . . . 7
2.2.1. Group Parameter Generation . . . . . . . . . . . . . . 7
2.2.1.1. Generation of p, q . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2
2. Overview Of Method . . . . . . . . . . . . . . . . . . . . 2
2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 2
2.1.1. Generation of ZZ . . . . . . . . . . . . . . . . . . . 3
2.1.2. Generation of Keying Material . . . . . . . . . . . . . 3
2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Keylengths for common algorithms . . . . . . . . . . . 5
2.1.5. Public Key Validation . . . . . . . . . . . . . . . . . 5
2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Key and Parameter Requirements . . . . . . . . . . . . . 7
2.2.1. Group Parameter Generation . . . . . . . . . . . . . . 7
2.2.1.1. Generation of p, q . . . . . . . . . . . . . . . . . 8
2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . . 9
2.2.2. Group Parameter Validation . . . . . . . . . . . . . . 9
2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . . 10
2.4. Static-Static Mode . . . . . . . . . . . . . . . . . . . 10
2.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 11
Security Considerations . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . . 9
2.2.2. Group Parameter Validation . . . . . . . . . . . . . . 9
2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . . 10
2.4. Static-Static Mode . . . . . . . . . . . . . . . . . . . 10
2.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 11
Security Considerations . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
In [DH76] Diffie and Hellman describe a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. This secret may then be converted into cryptographic keying material for other (symmetric) algorithms. A large number of minor variants of this process exist. This document describes one such variant, based on the ANSI X9.42 specification.
在[DH76]中，Diffie和Hellman描述了一种双方就共享秘密达成一致的方式，使得窃听者无法获得该秘密。然后可以将该秘密转换为用于其他（对称）算法的加密密钥材料。这一过程存在大量的次要变体。本文件描述了一种基于ANSI X9.42规范的此类变体。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
Diffie-Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining one's private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material. That keying material is typically used as a key-encryption key (KEK) to encrypt (wrap) a content-encryption key (CEK) which is in turn used to encrypt the message data.
Diffie-Hellman密钥协议要求消息的发送方和接收方都具有密钥对。通过组合一方的私钥和另一方的公钥，双方可以计算相同的共享密钥号。然后可以将该数字转换为加密密钥材料。该密钥材料通常用作密钥加密密钥（KEK）来加密（包装）内容加密密钥（CEK），而内容加密密钥又用于加密消息数据。
The first stage of the key agreement process is to compute a shared secret number, called ZZ. When the same originator and recipient public/private key pairs are used, the same ZZ value will result. The ZZ value is then converted into a shared symmetric cryptographic key. When the originator employs a static private/public key pair, the introduction of a public random value ensures that the resulting symmetric key will be different for each key agreement.
密钥协商过程的第一阶段是计算一个称为ZZ的共享密钥号。当使用相同的发起者和接收者公钥/私钥对时，将产生相同的ZZ值。然后将ZZ值转换为共享对称加密密钥。当发起人使用静态私钥/公钥对时，引入公共随机值可确保生成的对称密钥对于每个密钥协议都是不同的。
X9.42 defines that the shared secret ZZ is generated as follows:
X9.42定义共享秘密ZZ的生成如下：
ZZ = g ^ (xb * xa) mod p
ZZ = g ^ (xb * xa) mod p
Note that the individual parties actually perform the computations:
请注意，各方实际执行计算：
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
where ^ denotes exponentiation
其中^表示幂运算
ya is party a's public key; ya = g ^ xa mod p
yb is party b's public key; yb = g ^ xb mod p
xa is party a's private key
xb is party b's private key
p is a large prime
q is a large prime
g = h^{(p-1)/q} mod p, where
h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)
j a large integer such that p=qj + 1
(See Section 2.2 for criteria for keys and parameters)
ya is party a's public key; ya = g ^ xa mod p
yb is party b's public key; yb = g ^ xb mod p
xa is party a's private key
xb is party b's private key
p is a large prime
q is a large prime
g = h^{(p-1)/q} mod p, where
h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)
j a large integer such that p=qj + 1
(See Section 2.2 for criteria for keys and parameters)
In [CMS], the recipient's key is identified by the CMS RecipientIdentifier, which points to the recipient's certificate. The sender's public key is identified using the OriginatorIdentifierOrKey field, either by reference to the sender's certificate or by inline inclusion of a public key.
在[CMS]中，收件人的密钥由CMS RecipientIdentifier标识，该标识指向收件人的证书。通过引用发件人的证书或通过内联包含公钥，使用OriginatorIdentifierWorkey字段标识发件人的公钥。
X9.42 provides an algorithm for generating an essentially arbitrary amount of keying material from ZZ. Our algorithm is derived from that algorithm by mandating some optional fields and omitting others.
X9.42提供了一种从ZZ生成基本上任意数量的键控材料的算法。我们的算法是从该算法派生出来的，通过强制指定一些可选字段而忽略其他字段。
KM = H ( ZZ || OtherInfo)
KM=H（ZZ | |其他信息）
H is the message digest function SHA-1 [FIPS-180] ZZ is the shared secret value computed in Section 2.1.1. Leading zeros MUST be preserved, so that ZZ occupies as many octets as p. For instance, if p is 1024 bits, ZZ should be 128 bytes long. OtherInfo is the DER encoding of the following structure:
H是消息摘要函数SHA-1[FIPS-180]ZZ是第2.1.1节中计算的共享秘密值。必须保留前导零，以便ZZ占用的八位字节数与p的八位字节数相同。例如，如果p是1024位，那么ZZ应该是128字节长。OtherInfo是以下结构的DER编码：
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
partyAInfo [0] OCTET STRING OPTIONAL,
suppPubInfo [2] OCTET STRING
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
partyAInfo [0] OCTET STRING OPTIONAL,
suppPubInfo [2] OCTET STRING
}
}
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
counter OCTET STRING SIZE (4..4) }
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
counter OCTET STRING SIZE (4..4) }
Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT is explicitly specified.)
请注意，这些ASN.1定义使用显式标记。（在ASN.1中，除非明确指定隐式，否则显式标记是隐式的。）
algorithm is the ASN.1 algorithm OID of the CEK wrapping algorithm with which this KEK will be used. Note that this is NOT an AlgorithmIdentifier, but simply the OBJECT IDENTIFIER. No parameters are used.
算法是使用此KEK的CEK包装算法的ASN.1算法OID。请注意，这不是算法标识符，只是对象标识符。没有使用任何参数。
counter is a 32 bit number, represented in network byte order. Its initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 (hex), and it is incremented by one every time the above key generation function is run for a given KEK.
计数器是一个32位数字，以网络字节顺序表示。对于任何ZZ，其初始值为1，即字节序列00 01（十六进制），并且每当针对给定的KEK运行上述密钥生成函数时，其增量为1。
partyAInfo is a random string provided by the sender. In CMS, it is provided as a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If provided, partyAInfo MUST contain 512 bits.
PartyInfo是发件人提供的随机字符串。在CMS中，它作为参数提供在UserKeyingMaterial字段中（编码为八位字节字符串）。如果提供，PartyInfo必须包含512位。
suppPubInfo is the length of the generated KEK, in bits, represented as a 32 bit number in network byte order. E.g. for 3DES it would be the byte sequence 00 00 00 C0.
suppPubInfo是生成的KEK的长度，以位为单位，表示为网络字节顺序的32位数字。例如，对于3DES，它将是字节序列00 C0。
To generate a KEK, one generates one or more KM blocks (incrementing counter appropriately) until enough material has been generated. The KM blocks are concatenated left to right I.e. KM(counter=1) || KM(counter=2)...
要生成KEK，可以生成一个或多个KM块（适当增加计数器），直到生成足够的材质。KM块从左到右连接，即KM（计数器=1）| | KM（计数器=2）。。。
Note that the only source of secret entropy in this computation is ZZ. Even if a string longer than ZZ is generated, the effective key space of the KEK is limited by the size of ZZ, in addition to any security level considerations imposed by the parameters p and q. However, if partyAInfo is different for each message, a different KEK will be generated for each message. Note that partyAInfo MUST be used in Static-Static mode, but MAY appear in Ephemeral-Static mode.
请注意，在这个计算中，秘密熵的唯一来源是ZZ。即使生成了比ZZ长的字符串，KEK的有效密钥空间也受到ZZ大小的限制，除了参数p和q施加的任何安全级别考虑之外。但是，如果每条消息的partyAInfo不同，则会为每条消息生成不同的KEK。请注意，partyAInfo必须在静态模式下使用，但可能会在短暂静态模式下出现。
Each key encryption algorithm requires a specific size key (n). The KEK is generated by mapping the left n-most bytes of KM onto the key. For 3DES, which requires 192 bits of keying material, the algorithm must be run twice, once with a counter value of 1 (to generate K1', K2', and the first 32 bits of K3') and once with a counter value of 2
每个密钥加密算法都需要一个特定大小的密钥（n）。KEK是通过将KM的最左边n个字节映射到密钥上生成的。对于需要192位键控材料的3DES，算法必须运行两次，一次计数器值为1（生成K1'，K2'，和K3'的前32位），一次计数器值为2
(to generate the last 32 bits of K3). K1',K2' and K3' are then parity adjusted to generate the 3 DES keys K1,K2 and K3. For RC2-128, which requires 128 bits of keying material, the algorithm is run once, with a counter value of 1, and the left-most 128 bits are directly converted to an RC2 key. Similarly, for RC2-40, which requires 40 bits of keying material, the algorithm is run once, with a counter value of 1, and the leftmost 40 bits are used as the key.
（生成K3的最后32位）。然后对K1'，K2'和K3'进行奇偶校验调整，以生成3个DES键K1，K2和K3。对于需要128位密钥材料的RC2-128，算法运行一次，计数器值为1，最左边的128位直接转换为RC2密钥。类似地，对于需要40位键控材料的RC2-40，算法运行一次，计数器值为1，最左边的40位用作键。
Some common key encryption algorithms have KEKs of the following lengths.
一些常见的密钥加密算法的密钥长度如下。
3-key 3DES 192 bits RC2-128 128 bits RC2-40 40 bits
3密钥3DES 192位RC2-128位RC2-40位
RC2 effective key lengths are equal to RC2 real key lengths.
RC2有效密钥长度等于RC2实际密钥长度。
The following algorithm MAY be used to validate a received public key y.
以下算法可用于验证接收到的公钥y。
1. Verify that y lies within the interval [2,p-1]. If it does not, the key is invalid. 2. Compute y^q mod p. If the result == 1, the key is valid. Otherwise the key is invalid.
1. 确认y位于区间[2，p-1]内。如果没有，则密钥无效。2.计算y^q模p。如果结果==1，则该键有效。否则，密钥无效。
The primary purpose of public key validation is to prevent a small subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static mode is used, this check may not be necessary. See also [P1363] for more information on Public Key validation.
公钥验证的主要目的是防止对发送方密钥对的小子组攻击[LAW98]。如果使用临时静态模式，则无需进行此检查。有关公钥验证的更多信息，请参见[P1363]。
Note that this procedure may be subject to pending patents.
请注意，此程序可能受到正在申请的专利的限制。
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZ是10 11 12 13的20字节00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
The key wrap algorithm is 3DES-EDE wrap.
密钥包裹算法是3DES-EDE包裹。
No partyAInfo is used.
没有使用PartyInfo。
Consequently, the input to the first invocation of SHA-1 is:
因此，第一次调用SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ
30 1d 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID 04 04 00 00 00 01 ; Counter a2 06 04 04 00 00 00 c0 ; key length
30 1d 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06；3DES包裹OID 04 04 00 01；柜台a2 06 04 00 c0；键长
And the output is the 20 bytes:
输出为20个字节：
a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e
a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e
The input to the second invocation of SHA-1 is:
第二次调用SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 1d 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID 04 04 00 00 00 02 ; Counter a2 06 04 04 00 00 00 c0 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ 30 1d 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06；3DES包裹OID 04 04 00 02；柜台a2 06 04 00 c0；键长
And the output is the 20 bytes:
输出为20个字节：
f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30
f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30
Consequently, K1'=a0 96 61 39 23 76 f7 04 K2'=4d 90 52 a3 97 88 32 46 K3'=b6 7f 5f 1e f6 3e b5 fb
因此，K1'=a0 96 61 39 23 76 f7 04 K2'=4d 90 52 a3 97 88 32 46 K3'=b6 7f 5f 1e f6 3e b5 fb
Note: These keys are not parity adjusted
注意：这些键没有奇偶校验调整
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
ZZ是10 11 12 13的20字节00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
The key wrap algorithm is RC2-128 key wrap, so we need 128 bits (16 bytes) of keying material.
密钥封装算法是RC2-128密钥封装，因此我们需要128位（16字节）的密钥材料。
The partyAInfo used is the 64 bytes
使用的partyAInfo是64字节
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
Consequently, the input to SHA-1 is:
因此，SHA-1的输入为：
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 07 ; RC2 wrap OID 04 04 00 00 00 01 ; Counter a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 a2 06 04 04 00 00 00 80 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13；ZZ 30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 07；RC2包裹OID 04 00 01；计数器a0 42 04 40 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01；partyAInfo 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 23 45 67 89 ab cd ef fe dc ba 98 76 32 01 a2 06 04 00 00 80；键长
And the output is the 20 bytes:
输出为20个字节：
48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9
48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9
Consequently, K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0
因此，K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0
X9.42 requires that the group parameters be of the form p=jq + 1 where q is a large prime of length m and j>=2. An algorithm for generating primes of this form (derived from the algorithms in FIPS PUB 186-1[FIPS-186] and [X942]can be found in appendix A.
X9.42要求组参数的形式为p=jq+1，其中q是长度为m且j>=2的大素数。生成这种形式素数的算法（源自FIPS PUB 186-1[FIPS-186]和[X942]中的算法）见附录A。
X9.42 requires that the private key x be in the interval [2, (q - 2)]. x should be randomly generated in this interval. y is then computed by calculating g^x mod p. To comply with this memo, m MUST be >=160 bits in length, (consequently, q MUST be at least 160 bits long). When symmetric ciphers stronger than DES are to be used, a larger m may be advisable. p must be a minimum of 512 bits long.
X9.42要求私钥x在区间[2，（q-2）]内。应在此间隔内随机生成x。然后通过计算g^x mod p来计算y。为了遵守此备忘录，m的长度必须大于等于160位（因此，q的长度必须至少为160位）。当使用比DES更强的对称密码时，建议使用更大的m。p的最小长度必须为512位。
Agents SHOULD generate domain parameters (g,p,q) using the following algorithm, derived from [FIPS-186] and [X942]. When this algorithm is used, the correctness of the generation procedure can be verified by a third party by the algorithm of 2.2.2.
代理应使用以下算法生成域参数（g、p、q），该算法源自[FIPS-186]和[X942]。使用此算法时，第三方可通过2.2.2的算法验证生成过程的正确性。
This algorithm generates a p, q pair where q is of length m and p is of length L.
该算法生成一个p，q对，其中q的长度为m，p的长度为L。
1. Set m' = m/160 where / represents integer division with rounding upwards. I.e. 200/160 = 2.
1. 设置m'=m/160，其中/表示向上舍入的整数除法。即200/160=2。
2. Set L'= L/160
2. 设置L'=L/160
3. Set N'= L/1024
3. 设置N'=L/1024
4. Select an arbitrary bit string SEED such that the length of SEED >= m
4. 选择任意位字符串种子，使种子长度>=m
5. Set U = 0
5. 设置U=0
6. For i = 0 to m' - 1
6. 对于i=0到m'-1
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
Note that for m=160, this reduces to the algorithm of [FIPS-186]
注意，对于m=160，这将简化为[FIPS-186]的算法
U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].
U=SHA1[SEED]XOR SHA1[（SEED+1）mod 2^160]。
5. Form q from U by computing U mod (2^m) and setting the most significant bit (the 2^(m-1) bit) and the least significant bit to 1. In terms of boolean operations, q = U OR 2^(m-1) OR 1. Note that 2^(m-1) < q < 2^m
5. 通过计算U mod（2^m）并将最高有效位（2^（m-1）位）和最低有效位设置为1，从U形成q。就布尔运算而言，q=U或2^（m-1）或1。注意，2^（m-1）<q<2^m
6. Use a robust primality algorithm to test whether q is prime.
6. 使用鲁棒素性算法测试q是否为素数。
7. If q is not prime then go to 4.
7. 如果q不是素数，则转到4。
8. Let counter = 0
8. 设计数器=0
9. Set R = seed + 2*m' + (L' * counter)
9. 集合R=种子+2*m'+（L'*计数器）
10. Set V = 0
10. 设置V=0
12. For i = 0 to L'-1 do
12. 对于i=0到L'-1 do
V = V + SHA1(R + i) * 2^(160 * i)
V = V + SHA1(R + i) * 2^(160 * i)
13. Set W = V mod 2^L
13. 设置W=V模2^L
14. Set X = W OR 2^(L-1)
14. 设置X=W或2^（L-1）
Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
15. Set p = X - (X mod (2*q)) + 1
15. 设定p=X-（X模（2*q））+1
6. If p > 2^(L-1) use a robust primality test to test whether p is prime. Else go to 18.
6. 如果p>2^（L-1），则使用稳健素性测试来测试p是否为素数。否则去18。
17. If p is prime output p, q, seed, counter and stop.
17. 如果p是素数输出p，q，种子，计数器和停止。
18. Set counter = counter + 1
18. 设置计数器=计数器+1
19. If counter < (4096 * N) then go to 8.
19. 如果计数器<（4096*N），则转到8。
20. Output "failure"
20. 输出“失败”
Note: A robust primality test is one where the probability of a non-prime number passing the test is at most 2^-80. [FIPS-186] provides a suitable algorithm, as does [X942].
注：鲁棒素性测试是指非素数通过测试的概率最多为2^-80。[FIPS-186]和[X942]提供了合适的算法。
This section gives an algorithm (derived from [FIPS-186]) for generating g.
本节给出了生成g的算法（源自[FIPS-186]）。
1. Let j = (p - 1)/q.
1. 设j=（p-1）/q。
2. Set h = any integer, where 1 < h < p - 1 and h differs from any value previously tried.
2. 设置h=任何整数，其中1<h<p-1和h不同于先前尝试的任何值。
3. Set g = h^j mod p
3. 设置g=h^j模p
4. If g = 1 go to step 2
4. 如果g=1，则转至步骤2
The ASN.1 for DH keys in [PKIX] includes elements j and validation-Parms which MAY be used by recipients of a key to verify that the group parameters were correctly generated. Two checks are possible:
[PKIX]中DH密钥的ASN.1包括元素j和验证参数，密钥接收者可以使用这些元素来验证组参数是否正确生成。可以进行两种检查：
1. Verify that p=qj + 1. This demonstrates that the parameters meet the X9.42 parameter criteria. 2. Verify that when the p,q generation procedure of [FIPS-186] Appendix 2 is followed with seed 'seed', that p is found when 'counter' = pgenCounter.
1. 验证p=qj+1。这表明参数符合X9.42参数标准。2.验证当[FIPS-186]附录2中的p，q生成程序遵循种子“seed”时，当“counter”=PGF时，p被找到。
This demonstrates that the parameters were randomly chosen and do not have a special form.
这表明参数是随机选择的，没有特殊形式。
Whether agents provide validation information in their certificates is a local matter between the agents and their CA.
代理是否在其证书中提供验证信息是代理与其CA之间的本地问题。
In Ephemeral-Static mode, the recipient has a static (and certified) key pair, but the sender generates a new key pair for each message and sends it using the originatorKey production. If the sender's key is freshly generated for each message, the shared secret ZZ will be similarly different for each message and partyAInfo MAY be omitted, since it serves merely to decouple multiple KEKs generated by the same set of pairwise keys. If, however, the same ephemeral sender key is used for multiple messages (e.g. it is cached as a performance optimization) then a separate partyAInfo MUST be used for each message. All implementations of this standard MUST implement Ephemeral-Static mode.
在短暂静态模式下，收件人有一个静态（和认证）密钥对，但发件人为每条消息生成一个新的密钥对，并使用OriginateWorkey产品发送它。如果发送方的密钥是为每个消息新生成的，则共享密钥ZZ对于每个消息将类似地不同，并且partyAInfo可以省略，因为它仅用于解耦由相同的成对密钥集生成的多个kek。但是，如果同一临时发送方密钥用于多条消息（例如，作为性能优化缓存），则必须为每条消息使用单独的partyAInfo。本标准的所有实现都必须实现短暂的静态模式。
In order to resist small subgroup attacks, the recipient SHOULD perform the check described in 2.1.5. If an opponent cannot determine success or failure of a decryption operation by the recipient, the recipient MAY choose to omit this check. See also [LL97] for a method of generating keys which are not subject to small subgroup attack.
为了抵抗小子组攻击，接收方应执行2.1.5中所述的检查。如果对方无法确定收件人解密操作的成功或失败，收件人可以选择忽略此检查。另请参见[LL97]，了解生成不受小子组攻击的密钥的方法。
In Static-Static mode, both the sender and the recipient have a static (and certified) key pair. Since the sender's and recipient's keys are therefore the same for each message, ZZ will be the same for each message. Thus, partyAInfo MUST be used (and different for each message) in order to ensure that different messages use different KEKs. Implementations MAY implement Static-Static mode.
在静态模式下，发送方和接收方都有一个静态（和认证）密钥对。因此，由于发件人和收件人的密钥对于每条消息都是相同的，因此ZZ对于每条消息都是相同的。因此，为了确保不同的消息使用不同的KEK，必须使用partyAInfo（并且每个消息都不同）。实现可以实现静态模式。
In order to prevent small subgroup attacks, both originator and recipient SHOULD either perform the validation step described in Section 2.1.5 or verify that the CA has properly verified the validity of the key. See also [LL97] for a method of generating keys which are not subject to small subgroup attack.
为了防止小子组攻击，发起人和接收人都应执行第2.1.5节中描述的验证步骤，或者验证CA是否正确验证了密钥的有效性。另请参见[LL97]，了解生成不受小子组攻击的密钥的方法。
Acknowledgements
致谢
The Key Agreement method described in this document is based on work done by the ANSI X9F1 working group. The author wishes to extend his thanks for their assistance.
本文件中描述的关键协议方法基于ANSI X9F1工作组所做的工作。提交人谨对他们的协助表示感谢。
The author also wishes to thank Stephen Henson, Paul Hoffman, Russ Housley, Burt Kaliski, Brian Korver, John Linn, Jim Schaad, Mark Schertler, Peter Yee, and Robert Zuccherato for their expert advice and review.
作者还要感谢斯蒂芬·亨森、保罗·霍夫曼、罗斯·霍斯利、伯特·卡利斯基、布赖恩·科弗、约翰·林恩、吉姆·沙德、马克·舍特勒、彼得·叶和罗伯特·祖切拉托提供的专家建议和评论。
References
工具书类
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January 15).
[FIPS-46-1]联邦信息处理标准出版物（FIPS PUB）46-1，数据加密标准，1988年1月22日重申（取代FIPS PUB 46，1977年1月15日）。
[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[FIPS-81]联邦信息处理标准出版物（FIPS PUB）81，DES操作模式，1980年12月2日。
[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-180]联邦信息处理标准出版物（FIPS PUB）180-1，“安全哈希标准”，1995年4月17日。
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, "Digital Signature Standard", 1994 May 19.
[FIPS-186]联邦信息处理标准出版物（FIPS PUB）186，“数字签名标准”，1994年5月19日。
[P1363] "Standard Specifications for Public Key Cryptography", IEEE P1363 working group draft, 1998, Annex D.
[P1363]“公钥加密的标准规范”，IEEE P1363工作组草案，1998年，附录D。
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[PKIX]Housley，R.，Ford，W.，Polk，W.和D.Solo，“Internet X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An efficient protocol for authenticated key agreement", Technical report CORR 98-05, University of Waterloo, 1998.
法律，A. Menezes，M. Qu，J. Solinas和S. Vanstone，“一个有效的认证密钥协议协议”，技术报告CORR 98－05，滑铁卢大学，1998。
[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on discrete log-based schemes using a prime order subgroup", B.S. Kaliski, Jr., editor, Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.
[LL97]C.H.Lim和P.J.Lee，“使用素数阶子群对离散的基于日志的方案的密钥恢复攻击”，B.S.Kaliski，Jr.，编辑，《密码学进展-密码术'97》，计算机科学讲稿，第1295卷，1997年，Springer Verlag，第249-263页。
[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月。
[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", ANSI draft, 1998.
[X942]“使用Diffie-Hellman和MQV算法的对称密钥协议”，ANSI草稿，1998年。
Security Considerations
安全考虑
All the security in this system is provided by the secrecy of the private keying material. If either sender or recipient private keys are disclosed, all messages sent or received using that key are compromised. Similarly, loss of the private key results in an inability to read messages sent using that key.
该系统的所有安全性都由私钥材料的保密性提供。如果泄露了发件人或收件人的私钥，则使用该私钥发送或接收的所有邮件都会被泄露。类似地，私钥的丢失导致无法读取使用该密钥发送的消息。
Static Diffie-Hellman keys are vulnerable to a small subgroup attack [LAW98]. In practice, this issue arises for both sides in Static-Static mode and for the receiver during Ephemeral-Static mode. Sections 2.3 and 2.4 describe appropriate practices to protect against this attack. Alternatively, it is possible to generate keys in such a fashion that they are resistant to this attack. See [LL97]
静态Diffie-Hellman密钥容易受到小型子组攻击[LAW98]。在实践中，静态模式下的两侧和短暂静态模式下的接收器都会出现此问题。第2.3节和第2.4节描述了防止此攻击的适当做法。或者，可以生成密钥，使其能够抵抗此攻击。见[LL97]
The security level provided by these methods depends on several factors. It depends on the length of the symmetric key (typically, a 2^l security level if the length is l bits); the size of the prime q (a 2^{m/2} security level); and the size of the prime p (where the security level grows as a subexponential function of the size in bits). A good design principle is to have a balanced system, where all three security levels are approximately the same. If many keys are derived from a given pair of primes p and q, it may be prudent to have higher levels for the primes. In any case, the overall security is limited by the lowest of the three levels.
这些方法提供的安全级别取决于几个因素。它取决于对称密钥的长度（通常，如果长度为l位，则为2^l安全级别）；素数q的大小（2^{m/2}安全级别）；素数p的大小（其中安全级别作为大小的次指数函数以位为单位增长）。一个好的设计原则是拥有一个平衡的系统，其中所有三个安全级别大致相同。如果许多密钥是从给定的一对素数p和q导出的，那么为素数设置更高的级别可能是明智的。在任何情况下，总体安全性都受到三个级别中最低级别的限制。
Author's Address
作者地址
Eric Rescorla RTFM Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
Eric Rescorla RTFM Inc.加利福尼亚州东帕洛阿尔托市纽厄尔路30号，邮编：94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。