Network Working Group E. Rescorla
Request for Comments: 2631 RTFM Inc.
Category: Standards Track June 1999
Diffie-Hellman Key Agreement Method
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
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]ディフィー及びヘルマンでは両当事者が秘密盗聴者に利用できなくなるような方法で共有秘密合意するための手段を説明します。この秘密は、他の（対称）アルゴリズムのための暗号化キーイングマテリアルに変換することができます。このプロセスのマイナーな亜種が多数存在します。この文書では、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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT" と[RFC2119]で説明したように解釈されるべきであり、この文書に表示される "MAY"。
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鍵は、メッセージの送信者と受信者の両方が鍵のペアを持っていることが必要です。 1の秘密鍵と相手の公開鍵を組み合わせることにより、両者が同じ共有秘密数を計算することができます。この番号は、暗号化の鍵材料に変換することができます。その鍵材料は、典型的には、（ラップ）メッセージデータを暗号化するために使用される順番であるコンテンツ暗号鍵（CEK）を暗号化する鍵暗号鍵（KEK）として使用されます。
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 *）モッズ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）モッズ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 RecipientIdentifier、によって識別されます。送信者の公開鍵は、送信者の証明書を参照することによって、または公開鍵のインライン含めることのいずれかによって、OriginatorIdentifierOrKeyフィールドを使用して識別されます。
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 || 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定義はEXPLICITタグを使用することに注意してください。 （IMPLICITが明示的に指定されていない限り、ASN.1では、EXPLICITタグ付けは暗黙的です。）
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ビット数です。その初期値、すなわちバイトシーケンス00 00 00 01（16進数）、任意ZZための1であり、それは、一つ以上のキー生成関数は、指定されたKEKのために実行されるたびにインクリメントされます。
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には、（OCTET STRINGとして符号化された）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.
suppPubInfoは、生成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を生成するために、一つは一つ以上の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の有効な鍵空間は、パラメータ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鍵にKMの左N-最もバイトをマッピングすることによって生成されます。鍵材料の192ビットを必要と3DES、のために、アルゴリズムは、一度のカウンタ値がカウンタ（K1' を生成する、K2' 、及びK3' の最初の32ビット）1の値で1回、2回実行する必要があります2（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.
いくつかの共通鍵暗号アルゴリズムは、以下の長さののKEKを持っています。
3-key 3DES 192 bits RC2-128 128 bits RC2-40 40 bits
RC2-128 128ビットRC2-40 40ビット3キー3DES 192ビット
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 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
ZZは20バイト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
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
01 09 10 03 06 0D 30 1D 30 13 06 0B 2A 86 48 86 F7。 3DESラップOID 04 04 00 00 00 01。カウンターA2 06 04 04 00 00 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ヤシ61 ZYA 23 shtshのfshtのCHD 04 90 52 88 32 I yasht CHSH BSH shtf 5F 1F
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
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13。 0D ZZ 30 1D 30 13 06 0B 2A 86 48 86 F7 01 09 10 03 06。 3DESラップOID 04 04 00 00 00 02。カウンターA2 06 04 04 00 00 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は20バイト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直流BA 98の76 54 32 01 01 23 45 67 89 ABは、CD、EF FE直流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直流BA 98の76 54 32 01 01 23 45 67 89 ABは、CD、EF FE直流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。 01 09 10 03 07 0D ZZ 30 61 30 13 06 0B 2A 86 48 86 F7。 RC2ラップOID 04 04 00 00 00 01。カウンタA0 42 04 40 01 23 45 67 89 ABは、CD、EF FE直流BA 98 76 54 32 01。 partyAInfo 01 23 45 67 89 ABのCD EF FE直流BA 98 76 54 32 01 01 23 45 67 89 ABは、CD、EF FE直流BA 98 76 54 32 01 01 23 45 67 89 ABのCD EF FE直流BA 98 76 54 32 01 A2 06 04 00 00 00 80 04。キーの長さ
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 + 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は、[（ - 2 Q）2]、秘密鍵xが間隔であることを必要とします。 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.
このアルゴリズムは、Qが長さMであり、pは長さLであるP、Q対を生成します
1. Set m' = m/160 where / represents integer division with rounding upwards. I.e. 200/160 = 2.
1.集合M」/上向きに丸めると整数除算を表し= M / 160。即ち160分の200 = 2。
4. Select an arbitrary bit string SEED such that the length of SEED >= m
4.そのような任意ビット列SEEDを選択SEED> = Mの長さ
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
UのMOD（2 ^ m）を計算し、ブール演算の観点から1に、最上位ビット（2 ^（M-1）ビット）と最下位ビットを設定することにより、Uから5フォームQ、Q = U OR 2 ^（M-1）OR 1なお、2 ^（M-1）<Q <2 ^ M
V = V + SHA1(R + i) * 2^(160 * i)
B = B + IIIa1（R + S）×2 ^（160 * I）
Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
0 <= W <2 ^（L-1）、従ってX> = 2 ^（L-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に進みます。
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ものです。 [X942]ないようFIPS-186]は、適切なアルゴリズムを提供します。
This section gives an algorithm (derived from [FIPS-186]) for generating g.
このセクションでは、Gを生成する（[FIPS-186]に由来する）アルゴリズムを与えます。
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は以前に試みた任意の値と異なります。
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および検証-PARMSを含みます。 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.このパラメータはX9.42パラメータの基準を満たすことを証明しているただし、p = QJ + 1を確認してください。 2. [FIPS-186]付録2のP、Qの生成手順は、シード「シード」と続いている場合、そのpが場合「カウンタ」= 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は、各メッセージのために同様に異なるであろうと、それはペアワイズ鍵の同一のセットによって生成された複数のKEKを分離するために単になるため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は、メッセージごとに同じになります。したがって、partyAInfoは異なるメッセージが異なるのKEKを使用することを確実にするために（そしてメッセージごとに異なる）を使用しなければなりません。実装はスタティックスタティックモードを実装してもよいです。
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.
著者はまた、彼らの専門家のアドバイスやレビューのためにスティーブン・ヘンソン、ポール・ホフマン、ラスHousley、バート・カリスキー、ブライアン・コーバー、ジョン・リン、ジムSchaad、マークSchertler、ピーター・イー、およびロバートZuccheratoに感謝したいです。
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日（1977年1月15日、FIPS PUBの46に取って代わる）を再確認しました。
[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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネット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.法、A.メネゼス、M.ク、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.リムとP.J.・リー、「素のサブグループを使用して、離散対数ベースのスキームの鍵回復攻撃」、B.S.暗号'97、コンピュータサイエンス、巻で講義ノート - Kaliski、ジュニア、編集者は、暗号学の進歩します。 1295年、1997年、シュプリンガー・フェアラーク、頁249から263まで。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", ANSI draft, 1998.
、ANSIのドラフト、1998 [X942] "のDiffie-HellmanのとMQVアルゴリズムを用いた対称鍵の合意"。
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のサイズ。良いデザインの原則は、すべての3つのセキュリティレベルがほぼ同じであるバランスの取れたシステムを、持っていることです。多くのキーが素数pとqの所与の対に由来する場合、素数のために、より高いレベルを有することが賢明であり得ます。いずれの場合においても、全体的なセキュリティは、三つのレベルの最低によって制限されます。
Author's Address
著者のアドレス
Eric Rescorla RTFM Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
エリックレスコラRTFM株式会社30ニューウェル・ロード、＃16イーストパロアルト、CA 94303
EMail: ekr@rtfm.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。