[要約] RFC 2631は、Diffie-Hellman Key Agreement Methodに関する技術文書で、安全な鍵交換を可能にするためのプロトコルを定義しています。この文書の目的は、二者間で秘密鍵を共有することなく、公開鍵を用いて安全な通信チャネルを確立する方法を提供することです。主に、セキュアなメッセージング、VPN、TLS/SSLなどの暗号化通信プロトコルで利用されます。関連するRFCには、RFC 5246 (TLS 1.2) や RFC 8446 (TLS 1.3) などがあり、これらはDiffie-Hellman法を利用したセキュアな通信の確立に関連する技術仕様を提供しています。
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.
Copyright（c）The Internet Society（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は、共有された秘密に同意するために2つの当事者が使用する重要な契約アルゴリズムです。共有秘密を任意の量のキーイング材料に変換するためのアルゴリズムが提供されます。結果のキーイング材料は、対称暗号化キーとして使用されます。説明されている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
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は、秘密が盗聴者に利用できないように、共有された秘密に同意する2つの当事者が同意する手段を説明しています。この秘密は、その後、他の（対称）アルゴリズムの暗号化キーリング材料に変換される可能性があります。このプロセスの多数の小さなバリエーションが存在します。このドキュメントでは、ANSI X9.42仕様に基づいて、そのようなバリアントの1つについて説明します。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
このドキュメントで使われるキーワード "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" は[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）を暗号化（wrap）します。これは、メッセージデータの暗号化に使用されます。
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
Note that the individual parties actually perform the computations:
個々の当事者が実際に計算を実行することに注意してください。
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)
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 Recipientientifientifierによって識別されます。送信者の公開キーは、送信者の証明書を参照するか、公開鍵をインラインで含めることにより、Originatorideidierorkeyフィールドを使用して識別されます。
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)
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
}
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です。これはAlgorithmidentifierではなく、単にオブジェクト識別子であることに注意してください。パラメーターは使用されません。
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の場合、つまりバイトシーケンス 00 00 00 01（16進数）で、上記のキー生成関数が特定の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.
partyainfoは、送信者によって提供されるランダムな文字列です。CMSでは、userkeyingmaterialフィールド（オクテット文字列としてエンコード）のパラメーターとして提供されます。提供されている場合、partyainfoには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.
duppubinfoは、生成されたkekの長さ、ビットで、ネットワークバイトの順序で32ビット数として表されます。例えば。3DESの場合、それはバイトシーケンス 00 00 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を生成するには、十分な材料が生成されるまで1つ以上のkmブロック（適切に拡大する）を生成します。KMブロックは左から右に連結されています。km(counter=1) || km(counter=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の有効なキー空間は、パラメーターPとQによって課されるセキュリティレベルの考慮事項に加えて、ZZのサイズによって制限されます。ただし、各メッセージごとに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 (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.
各キー暗号化アルゴリズムには、特定のサイズキー（n）が必要です。kekは、左n最大バイトのkmをキーにマッピングすることにより生成されます。192ビットのキーイング材料を必要とする3DESの場合、アルゴリズムは2回実行する必要があります。1回（K1 '、k2'、および最初の32ビットのK3 'を生成するために）、1回のカウンター値で1回実行する必要があります。2（K3の最後の32ビットを生成するため）。K1 '、K2'、K3 'は、パリティが調整され、3 DESキーK1、K2、K3が生成されます。128ビットのキーイング材料を必要とするRC2-128の場合、アルゴリズムは1回実行され、カウンター値は1で、左128ビットはRC2キーに直接変換されます。同様に、40ビットのキーイン素材を必要とするRC2-40の場合、アルゴリズムが1回実行され、カウンター値は1で、左端40ビットがキーとして使用されます。
Some common key encryption algorithms have KEKs of the following lengths.
いくつかの一般的なキー暗号化アルゴリズムには、次の長さのKEKsがあります。
3-key 3DES 192 bits
RC2-128 128 bits
RC2-40 40 bits
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.
1. yが間隔内にあることを確認します [2,p-1]。そうでない場合、キーは無効です。
2. Compute y^q mod p. If the result == 1, the key is valid. Otherwise the key is invalid.
2. y^q mod 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
The key wrap algorithm is 3DES-EDE wrap.
キーラップアルゴリズムは3DES-EDEラップです。
No partyAInfo is used.
partyainfoは使用されません。
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
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
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
The input to the second invocation of SHA-1 is:
SHA-1の2回目の呼び出しへの入力は次のとおりです。
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
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
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
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
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
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
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
Consequently,
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は、この間隔でランダムに生成する必要があります。yは、g^x mod pを計算して計算されます。このメモに準拠するには、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.
エージェントは、[FIPS-186]および[x942]から派生した次のアルゴリズムを使用して、ドメインパラメーター（g、p、q）を生成する必要があります。このアルゴリズムを使用すると、生成手順の正確性は、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)
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 ].
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. counter = 0 とします。
9. Set R = seed + 2*m' + (L' * counter)
9. Set R = seed + 2*m' + (L' * counter)
10. Set V = 0
10. V = 0 を設定します
12. For i = 0 to L'-1 do
12. i = 0 から L'-1 まで以下を繰り返します：
V = V + SHA1(R + i) * 2^(160 * i)
13. Set W = V mod 2^L
13. W = V mod 2^L を設定します
14. Set X = W OR 2^(L-1) Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
14. X = W OR 2^(L-1) を計算します。ただし、0 <= W < 2^(L-1) なので X >= 2^(L-1) です。
15. Set p = X - (X mod (2*q)) + 1
15. p = X - (X mod (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. counter = counter + 1 を設定します。
19. If counter < (4096 * N) then go to 8.
19. counter < (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 mod 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と検証パーマムが含まれています。2つのチェックが可能です。
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]のp、q生成手順の付録2のq生成手順がシード「種」に続くと、pが「counter」= pgenCounter のときに見つかったことを確認します。
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.
短命モードでは、受信者は静的（および認定された）キーペアを持っていますが、送信者は各メッセージの新しいキーペアを生成し、OriginatorKeyの生産を使用して送信します。送信者のキーが各メッセージに対して新たに生成された場合、共有された秘密ZZはメッセージごとに同様に異なり、PartyAinfoは省略される可能性があります。ただし、複数のメッセージに同じはかない送信者キーが使用されている場合（たとえば、パフォーマンスの最適化としてキャッシュされます）、各メッセージに対して個別の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]も参照してください。
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.
著者はまた、スティーブン・ヘンソン、ポール・ホフマン、ラス・ヒューズリー、バート・カリスキ、ブライアン・コルバー、ジョン・リン、ジム・シャード、マーク・シェルトラー、ピーター・イー、ロバート・ズッチェラートの専門家のアドバイスとレビューに感謝したいと考えています。
[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日の再確認（Supersedes 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 Modes of Operation、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、「Secure Hash Standard」、1995年4月17日。
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, "Digital Signature Standard", 1994 May 19.
[FIPS-186]連邦情報処理標準出版（FIPS Pub）186、「Digital Signature Standard」、1994年5月19日。
[P1363] "Standard Specifications for Public Key Cryptography", IEEE P1363 working group draft, 1998, Annex D.
[P1363]「公開キー暗号化の標準仕様」、IEEE P1363ワーキンググループドラフト、1998、Annex 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。and 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.
[Law98] L. Law、A。Menezes、M。Qu、J。SolinasおよびS. Vanstone、「認証された主要な合意のための効率的なプロトコル」、テクニカルレポートCorr 98-05、Waterloo、University of Waterloo、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、「Prime Order Subgroupを使用した離散ログベースのスキームに対する重要な回復攻撃」、B.S。Kaliski、Jr。、編集者、CryptologyのAdvances -Crypto '97、講義ノートのComputer Science、Vol。1295、1997、Springer-Verlag、pp。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 Algorithmsを使用した対称キーの一致」、ANSI Draft、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（a 2^{m/2}セキュリティレベル）のサイズ;プライムPのサイズ（セキュリティレベルがビット内のサイズのサブエクスポンシャル関数として成長します）。優れた設計の原則は、3つのセキュリティレベルすべてがほぼ同じであるバランスの取れたシステムを持つことです。多くのキーが特定のプライムPとQのペアから派生している場合、プライムのより高いレベルを持つことは賢明かもしれません。いずれにせよ、全体的なセキュリティは3つのレベルの中で最低に制限されます。
Author's Address
著者の連絡先
Eric Rescorla RTFM Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
Eric Rescorla RTFM Inc. 30 Newell Road、＃16 East Palo Alto、CA 94303
EMail: ekr@rtfm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。