[要約] RFC 2785は、Diffie-Hellman鍵共有方法における「小集団攻撃」を回避するための方法を提案しています。このRFCの目的は、S/MIMEにおける鍵共有のセキュリティを向上させることです。
Network Working Group R. Zuccherato
Request for Comments: 2785 Entrust Technologies
Category: Informational March 2000
Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
S/MIMEのDiffie-Hellmanキー契約方法に対する「小型」攻撃を回避する方法
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.
状況によっては、大規模なプライムPのプライムオーダーサブグループでのdiffie-hellmanキー契約スキームの使用は、「小型グループ」攻撃として知られる特定の攻撃に対して脆弱です。ただし、これらの攻撃を防ぐ方法は存在します。このドキュメントでは、保護が必要なS/MIMEバージョン3の実装に関連する状況と、これらの攻撃を防ぐために使用できる方法について説明します。
This document will describe those situations in which protection from "small-subgroup" type attacks is necessary when using Diffie-Hellman key agreement [RFC2631] in implementations of S/MIME version 3 [RFC2630, RFC2633]. Thus, the ephemeral-static and static-static modes of Diffie-Hellman will be focused on. Some possible non-S/MIME usages of CMS are also considered, though with less emphasis than the cases arising in S/MIME. The situations for which protection is necessary are those in which an attacker could determine a substantial portion (i.e. more than a few bits) of a user's private key.
このドキュメントでは、S/MIMEバージョン3 [RFC2630、RFC2633]の実装でDiffie-Hellmanキー契約[RFC2631]を使用する場合、「小型グループ」タイプの攻撃からの保護が必要な状況について説明します。したがって、Diffie-Hellmanのはかない静的で静的な静的モードが焦点を当てます。S/MIMEで発生する場合よりも重点が少ないものの、CMSの非S/MIME使用のいくつかも考慮されます。保護が必要な状況は、攻撃者がユーザーの秘密鍵のかなりの部分（つまり、数ビット以上）を決定できる状況です。
Protecting oneself from these attacks involves certain costs. These costs may include additional processing time either when a public key is certified or a shared secret key is derived, increased parameter generation time, and possibly the licensing of encumbered technologies. All of these factors must be considered when deciding whether or not to protect oneself from these attacks, or whether to engineer the application so that protection is not necessary.
これらの攻撃から身を守るには、特定の費用が伴います。これらのコストには、公開キーが認定されている場合、または共有シークレットキーが派生した場合の追加処理時間、パラメーター生成時間の増加、およびおそらく邪魔されたテクノロジーのライセンスが含まれます。これらの要因はすべて、これらの攻撃から自分自身を保護するかどうか、または保護が必要でないようにアプリケーションを設計するかどうかを決定する際に考慮する必要があります。
We will not consider "attacks" where the other party in the key agreement merely forces the shared secret value to be "weak" (i.e. from a small set of possible values) without attempting to compromise the private key. It is not worth the effort to attempt to prevent these attacks since the other party in the key agreement gets the shared secret and can simply make the plaintext public.
キー契約の相手が共有された秘密の価値を単に秘密鍵を妥協しようとせずに「弱い」（つまり、小さな値のセットから）強制するだけである場合、「攻撃」を考慮しません。主要な契約の相手が共有された秘密を獲得し、単純にプレーンテキストを公開することができるため、これらの攻撃を防止しようとする努力の価値はありません。
The methods described in this memo may also be used to provide protection from similar attacks on elliptic curve based Diffie-Hellman.
このメモで説明されている方法は、楕円曲線ベースのdiffie-hellmanに対する同様の攻撃からの保護を提供するためにも使用できます。
In this document we will use the same notation as in [RFC2631]. In particular the shared secret ZZ is generated as follows:
このドキュメントでは、[RFC2631]と同じ表記を使用します。特に、共有された秘密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; xa is in the interval [2, (q - 2)]
xb is Party B's private key; xb is in the interval [2, (q - 2)]
p 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)
q is a large prime
j a large integer such that p=q*j + 1
In this discussion, a "static" public key is one that is certified and is used for more than one key agreement, and an "ephemeral" public key is one that is not certified but is used only one time.
この議論では、「静的な」公開キーは認定されたものであり、複数のキー契約に使用されるものであり、「はかない」公開キーは認定されていないが、1回しか使用されていないものです。
The order of an integer y modulo p is the smallest value of x greater than 1 such that y^x mod p = 1.
整数yモジュロPの順序は、y^x mod p = 1よりも1より大きいxの最小値です。
For a complete description of these attacks see [LAW] and [LIM].
これらの攻撃の完全な説明については、[法律]と[LIM]を参照してください。
If the other party in an execution of the Diffie-Hellman key agreement method has a public key not of the form described above, but of small order (where small means less than q) then he/she may be able to obtain information about the user's private key. In particular, if information on whether or not a given decryption was successful is available, if ciphertext encrypted with the agreed upon key is available, or if a MAC computed with the agreed upon key is available, information about the user's private key can be obtained.
diffie-hellmanキー契約法の実行中の他の当事者が上記のフォームではなく、小さな順序の公開鍵を持っている場合（小さいことはq未満の場合）、彼/彼女はユーザーの秘密鍵。特に、特定の復号化が成功したかどうかに関する情報が利用可能である場合、合意されたキーで暗号化された暗号文が利用可能である場合、または合意されたキーで計算されたMacが利用可能な場合、ユーザーの秘密キーに関する情報を取得できます。
Assume Party A has a valid public key ya and that Party B has a public key yb that is not of the form described in Section 1.1, rather yb has order r, where r is much less than q. Thus yb^r=1 mod p. Now, when Party A produces ZZ as yb^xa mod p, there will only be r possible values for ZZ instead of q-3 possible values. At this point Party B does not know the value ZZ, but may be able to exhaustively search for it.
党Aに有効な公開キーYAがあり、その党Bにはセクション1.1で説明されているフォームではない公開キーYBがあり、YBにはrがqよりもはるかに少ない注文Rがあります。したがって、yb^r = 1 mod p。現在、パーティーAがYb^Xa mod PとしてZZを生成する場合、Q-3の可能性のある値ではなく、ZZのRの可能な値のみがあります。この時点で、パーティーBは価値ZZを知らないが、それを徹底的に検索できる可能性がある。
If Party A encrypts plaintext with this value and makes that ciphertext available to Party B, Party B only needs to exhaustively search through r possibilities to determine which key produced the ciphertext. When the correct one is found, this gives information about the value of xa modulo r. Similarly, if Party A uses ZZ to decrypt a ciphertext and Party B is able to determine whether or not decryption was performed correctly, then information about xa can be obtained. The actual number of messages that must be sent or received for these attacks to be successful will depend on the structure of the prime p. However, it is not unreasonable to expect that the entire private key could be determined after as few as one hundred messages.
パーティーAがこの値でプレーンテキストを暗号化し、その暗号文をパーティーBで利用できるようにする場合、パーティーBは、どのキーがCiphertextを生成したかを決定するためにRの可能性を徹底的に検索するだけです。正しいものが見つかった場合、これはXa modulo rの値に関する情報を提供します。同様に、パーティAがZZを使用して暗号文を復号化し、パーティBが復号化が正しく実行されたかどうかを判断できる場合、XAに関する情報を取得できます。これらの攻撃を成功させるために送信または受信しなければならないメッセージの実際の数は、プライムpの構造に依存します。ただし、秘密鍵全体がわずか100のメッセージの後に決定できることを期待することは不合理ではありません。
A similar attack can be mounted if Party B chooses a public key of the form yb=g^xb*f, where f is an element of small order. In this situation Party A will compute ZZ=yb^xa=g^(xa*xb)*f^xa mod p. Again, Party B can compute g^(xa*xb) and can therefore exhaust the small number of possible values of f^xa mod p to determine information about xa.
パーティーBがフォームyb = g^xb*fの公開キーを選択した場合、同様の攻撃を取り付けることができます。ここで、fは小さな順序の要素です。この状況では、a aはzz = yb^xa = g^（xa*xb）*f^xa mod pを計算します。繰り返しますが、パーティーBはg^（xa*xb）を計算でき、したがって、f^xa mod pの少数の可能な値を排出してxaに関する情報を決定できます。
An attack is also possible if Party B has a public key yb of order r where r factors into small integers but is not necessarily a small integer itself. In this case, the attacker needs to know the value ZZ computed by Party A. From this value Party B can solve for Party A's private key modulo r using the Pohlig-Hellman [PH] algorithm.
パーティーBには、Rが小整数に因子を因子にするが、必ずしも小整数自体ではない注文Rの公開キーYBがある場合、攻撃も可能です。この場合、攻撃者は、党Aによって計算されたZZの価値を知る必要があります。
However, this attack is not as practical as the cases already presented, where information about the private key is recovered from the *use* of ZZ, rather than ZZ itself, by exhaustive search.
ただし、この攻撃は、既に提示されたケースほど実用的ではありません。ここでは、秘密鍵に関する情報がZZ自体ではなく、ZZの使用 *から回復され、徹底的な検索によって回復されます。
This section describes the situations in which the sender of a message should obtain protection against this type of attack and also those situations in which the receiver of a message should obtain protection. Each entity may decide independently whether it requires protection from these attacks.
このセクションでは、メッセージの送信者がこのタイプの攻撃に対する保護を取得する状況と、メッセージの受信者が保護を取得する状況について説明します。各エンティティは、これらの攻撃からの保護が必要かどうかを独立して決定する場合があります。
This discussion assumes that the recipient's key pair is static, as is always the case in [RFC2631].
この議論では、[RFC2631]の場合は常にそうであるように、受信者の重要なペアが静的であると想定しています。
This section describes situations in which the message sender should be protected.
このセクションでは、メッセージ送信者を保護する状況について説明します。
If the sender's key is ephemeral, (i.e. ephemeral-static Diffie-Hellman is being used), then no protection is necessary. In this situation only the recipients of the message can obtain the plaintext and corresponding ciphertext and therefore determine information about the private key using the "small-subgroup" attacks. However, the recipients can always decrypt the message and since the sender's key is ephemeral, even if the recipient can learn the entire private key no other messages are at risk. Notice here that if two or more recipients have selected the same domain parameters (p,q,g) then the same ephemeral public key can be used for all of them. Since the key is ephemeral and only associated with a message that the recipients can already decrypt, no interesting attacks are possible.
送信者の鍵が一時的なものである場合（すなわち、はかない舞台のdiffie-hellmanが使用されている場合）、保護は必要ありません。この状況では、メッセージの受信者のみがプレーンテキストと対応する暗号文を取得し、したがって「小型グループ」攻撃を使用して秘密鍵に関する情報を決定できます。ただし、受信者は常にメッセージを復号化できます。送信者のキーは一時的なものであるため、受信者が他のメッセージが危険にさらされていない秘密鍵全体を学習できても。ここでは、2人以上の受信者が同じドメインパラメーター（P、Q、G）を選択した場合、同じ一時的な公開キーをすべて使用できることに注意してください。キーは一時的であり、受信者がすでに復号化できるというメッセージにのみ関連付けられているため、興味深い攻撃は不可能です。
If the sender's key is static (i.e. static-static Diffie-Hellman is being used), then protection is necessary because in this situation a recipient mounting a small-subgroup attack may be able to obtain the plaintext from another recipient (perhaps one with a valid public key also controlled by the recipient) and therefore could obtain information about the private key. Moreover, the attacker does not need to know the plaintext to test whether a key is correct, provided that the plaintext has sufficient redundancy (e.g., ASCII). This information could then be used to attack other messages protected with the same static key.
送信者のキーが静的である場合（すなわち、静的な静的diffie-hellmanが使用されている場合）、この状況では、小型グループ攻撃を取り付ける受信者が別の受信者から平文を取得できる可能性があるため、保護が必要です（おそらく、受信者によって制御される有効な公開鍵もあり、したがって、秘密鍵に関する情報を取得できます。さらに、攻撃者は、プレーンテキストに十分な冗長性（ASCIIなど）がある場合、キーが正しいかどうかをテストするために平文を知る必要はありません。この情報は、同じ静的キーで保護されている他のメッセージを攻撃するために使用できます。
This section describes situations in which the message recipient should be protected.
このセクションでは、メッセージ受信者を保護する状況について説明します。
If absolutely no information on the decryption of the ciphertext is available to any other party than the recipient, then protection is not necessary because this attack requires information on whether the decryption was successful to be sent to the attacker. So, no protective measures are necessary if the implementation ensures that no information about the decryption can leak out. However, protection may be warranted if human users may give this information to the sender via out of band means (e.g. through telephone conversations).
暗号文の復号化に関する情報がレシピエント以外の当事者に利用可能である場合、この攻撃には攻撃者に送信されることが成功したかどうかに関する情報が必要なため、保護は必要ありません。したがって、実装が復号化に関する情報が漏れないことを保証する場合、保護対策は必要ありません。ただし、人間のユーザーがバンドの手段を介してこの情報を送信者に提供できる場合（たとえば、電話での会話を介して保護が保護される場合があります。
If information on the decryption is available to any other party, then protection is necessary. In particular, protection is necessary if any protocol event allows any other party to conclude that decryption was successful. Such events include replies and returning signed receipts.
復号化に関する情報が他の当事者が利用できる場合、保護が必要です。特に、プロトコルイベントが他の当事者が復号化が成功したと結論付けることができる場合、保護が必要です。このようなイベントには、返信と署名された領収書の返却が含まれます。
This section describes five protective measures that senders and recipients of messages can use to protect themselves from "small-subgroup" attacks.
このセクションでは、送信者とメッセージの受信者が「小型グループ」攻撃から身を守るために使用できる5つの保護対策について説明します。
Implementers should note that some of the procedures described in this section may be the subject of patents or pending patents.
実装者は、このセクションで説明する手順の一部が特許または保留中の特許の対象である可能性があることに注意する必要があります。
This method is described in Section 2.1.5 of [RFC2631], and its description is repeated here. If this method is used, it should be used to validate public keys of the other party prior to computing the shared secret ZZ. The public key to be validated is y.
この方法は、[RFC2631]のセクション2.1.5で説明されており、その説明はここで繰り返されます。この方法を使用する場合は、共有された秘密ZZを計算する前に、相手の公開キーを検証するために使用する必要があります。検証される公開鍵は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 Certification Authority (CA) could perform the Public Key Validation method described in Section 3.1 prior to signing and issuing a certificate containing a Diffie-Hellman public key. In this way, any party using the public key can be assured that a trusted third party has already performed the key validation process. This method is only viable for static public keys. When Static-Static Diffie-Hellman is employed, both the sender and recipient are protected when the CA has performed public key validation. However, when Ephemeral-Static Diffie-Hellman is employed, only the sender can be protected by having the CA perform public key validation. Since the sender generates an ephemeral public key, the CA cannot perform the validation on that public key.
認証機関（CA）は、Diffie-Hellmanの公開キーを含む証明書に署名および発行する前に、セクション3.1で説明した公開キー検証方法を実行できます。このようにして、公開キーを使用する当事者は、信頼できる第三者がすでにキー検証プロセスを実行していることを保証できます。この方法は、静的なパブリックキーに対してのみ実行可能です。静的な静的diffie-hellmanが採用されると、CAが公開キーの検証を行ったときに送信者と受信者の両方が保護されます。ただし、はかない静的なdiffie-hellmanが採用されている場合、CAに公開キーの検証を実行することにより、送信者のみが保護できます。送信者は一時的な公開キーを生成するため、CAはその公開キーで検証を実行できません。
In the case of a static public key a method must exist to assure the user that the CA has actually performed this verification. The CA can notify certificate users that it has performed the validation by reference to the CA's Certificate Policy (CP) and Certification Practice Statement (CPS) [RFC2527] or through extensions in the certificate.
静的な公開キーの場合、CAが実際にこの検証を実行したことをユーザーに保証するためにメソッドが存在する必要があります。CAは、CAの証明書ポリシー（CP）および認定慣行声明（CPS）[RFC2527]を参照することにより、または証明書の拡張を通じて、証明書ユーザーに検証を実行したことをユーザーに通知できます。
The prime p could be chosen such that p-1=2*q*k where k is a large prime or is the product of large primes (large means greater than or equal to q). This will prevent an attacker from being able to find an element (other than 1 and p-1) of small order modulo p, thus thwarting the small-subgroup attack. One method to produce primes of this form is to run the prime generation algorithm multiple times until an appropriate prime is obtained. As an example, the value of k could be tested for primality. If k is prime, then the value of p could be accepted, otherwise the prime generation algorithm would be run again, until a value of p is produced with k prime.
プライムPは、p-1 = 2*q*kが大きなプライムであるか、大きな素数の産物である（q以上の大きな平均）よりも選択できます。これにより、攻撃者が小さな順序モジュロPの要素（1およびP-1以外）を見つけることができなくなるため、小型グループ攻撃が妨げられます。このフォームのプライムを作成する1つの方法は、適切なプライムが取得されるまでプライムジェネレーションアルゴリズムを複数回実行することです。例として、Kの値は原始性をテストできます。Kがプライムの場合、Pの値を受け入れることができます。そうしないと、Pの値がK Primeで生成されるまで、Prime Generationアルゴリズムが再び実行されます。
However, since with primes of this form there is still an element of order 2 (i.e. p-1), one bit of the private key could still be lost. Thus, this method may not be appropriate in circumstances where the loss of a single bit of the private key is a concern.
ただし、このフォームのプライムが依然として注文2（すなわちP-1）の要素があるため、秘密鍵の1つがまだ失われる可能性があります。したがって、この方法は、単一のビットの秘密鍵を失うことが懸念事項である状況では適切ではないかもしれません。
Another method to produce primes of this form is to choose the prime p such that p = 2*q*k + 1 where k is small (i.e. only a few bits). In this case, the leakage due to a small subgroup attack will be only a few bits. Again, this would not be appropriate for circumstances where the loss of even a few bits of the private key is a concern. In this approach, q is large. Note that in DSA, q is limited to 160 bits for performance reasons, but need not be the case for Diffie-Hellman.
このフォームの素数を生成する別の方法は、p = 2*q*k 1が小さい（つまり、わずかなビットのみ）ようにプライムPを選択することです。この場合、小さなサブグループ攻撃による漏れはわずか数ビットになります。繰り返しますが、これは、秘密鍵の数ビットでさえも紛失している状況が懸念事項である場合には適していません。このアプローチでは、Qは大きいです。DSAでは、Qはパフォーマンス上の理由で160ビットに制限されていますが、Diffie-Hellmanの場合はそうではないことに注意してください。
Additionally, other methods (i.e. public key validation) can be combined with this method in order to prevent the loss of a few bits of the private key.
さらに、秘密鍵の数ビットの損失を防ぐために、他の方法（つまり、公開キーの検証）をこの方法と組み合わせることができます。
This method of protection is specified in [P1363] and [KALISKI]. It involves modifying the computation of ZZ by including j (the cofactor) in the computations and is compatible with ordinary Diffie-Hellman when both parties' public keys are valid. If a party's public key is invalid, then the resulting ZZ will either be 1 or an element of order q; the small subgroup elements will either be detected or cancelled. This method requires that gcd(j,q)=1.
この保護方法は、[P1363]および[Kaliski]で指定されています。計算にJ（補因子）を含めることによりZZの計算を変更することを伴い、両当事者の公開キーが有効である場合、通常のDiffie-Hellmanと互換性があります。当事者の公開鍵が無効である場合、結果のZZは1または注文qの要素になります。小さなサブグループ要素は検出またはキャンセルされます。この方法では、GCD（J、Q）= 1が必要です。
Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^c mod p where c=j^(-1)*xa mod q. (Similarly for Party B.)
zzをzz = yb^xa mod pとして計算する代わりに、パーティAはzz =（yb^j）^c mod pとして計算します。ここで、c = j^（ - 1）*xa mod q。（パーティーBについても同様に）
If the resulting value ZZ satisfies ZZ==1, then the key agreement should be abandoned because the public key being used is invalid.
結果の値ZZがZZ == 1を満たす場合、使用されている公開鍵が無効であるため、キー契約を放棄する必要があります。
Note that when j is larger than q, as is usually the case with Diffie-Hellman, this method is less efficient than the method of Section 3.1.
jがQよりも大きい場合、通常はDiffie-Hellmanの場合と同様に、この方法はセクション3.1の方法よりも効率が低いことに注意してください。
This method of protection is specified in [P1363]. Similar to the method of Section 3.4, it involves modifying the computation of ZZ by including j (the cofactor) in the computations. If a party's public key is invalid, then the resulting ZZ will either be 1 or an element of order q; the small subgroup elements will either be detected or cancelled. This method requires that gcd(j,q)=1.
この保護方法は[P1363]で指定されています。セクション3.4の方法と同様に、計算にJ（補因子）を含めることによりZZの計算を変更することが含まれます。当事者の公開鍵が無効である場合、結果のZZは1または注文qの要素になります。小さなサブグループ要素は検出またはキャンセルされます。この方法では、GCD（J、Q）= 1が必要です。
Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^xa mod p. (Similarly for Party B.) However, with this method the resulting ZZ value is different from what is computed in [RFC2631] and therefore is not interoperable with implementations conformant to [RFC2631].
zzをzz = yb^xa mod pとして計算する代わりに、パーティAはzz =（yb^j）^xa mod pとして計算します。（同様に党Bの場合）が、この方法では、結果のZZ値は[RFC2631]で計算されているものとは異なるため、[RFC2631]に適合する実装と相互運用できません。
If the resulting value ZZ satisfies ZZ==1, then the key agreement should be abandoned because the public key being used is invalid.
結果の値ZZがZZ == 1を満たす場合、使用されている公開鍵が無効であるため、キー契約を放棄する必要があります。
Note that when j is larger than q, as is usually the case with Diffie-Hellman, this method is less efficient than the method of Section 3.1.
jがQよりも大きい場合、通常はDiffie-Hellmanの場合と同様に、この方法はセクション3.1の方法よりも効率が低いことに注意してください。
This situation is when both the sender and recipient of a message are using ephemeral keys. While this situation is not possible in S/MIME, it might be used in other protocol environments. Thus we will briefly discuss protection for this case as well.
この状況は、メッセージの送信者と受信者の両方が短命キーを使用している場合です。この状況はS/MIMEでは不可能ですが、他のプロトコル環境で使用される場合があります。したがって、このケースの保護についても簡単に説明します。
Implementers should note that some of the procedures described in this section may be the subject of patents or pending patents.
実装者は、このセクションで説明する手順の一部が特許または保留中の特許の対象である可能性があることに注意する必要があります。
Ephemeral-ephemeral key agreement gives an attacker more flexibility since both parties' public keys can be changed and they can be coerced into computing the same key from a small space. However, in the ephemeral-static case, only the sender's public key can be changed, and only the recipient can be coerced by an outside attacker into computing a key from a small space.
一時的なfemeral-femeralキー契約は、両当事者のパブリックキーを変更できるため、攻撃者に柔軟性を与え、小さなスペースから同じキーを計算するように強制される可能性があるためです。ただし、一時的な静的の場合、送信者の公開鍵のみを変更でき、外部の攻撃者が小さなスペースからキーを計算するように強制されることができます。
Thus, in some ephemeral-ephemeral key agreements protection may be necessary for both entities. One possibility is that the attacker could modify both parties' public key so as to make their shared key predictable. For example, the attacker could replace both ya and yb with some element of small order, say -1. Then, with a certain probability, both the sender and receiver would compute the same shared value that comes from some small, easily exhaustible set.
したがって、いくつかの短命著しい主要契約では、両方のエンティティに保護が必要になる場合があります。1つの可能性は、攻撃者が共有キーを予測可能にするために、両当事者の公開鍵を変更できることです。たとえば、攻撃者は、YAとYBの両方を小さな注文の要素（-1など）に置き換えることができます。次に、特定の確率で、送信者と受信機の両方が、小さくて簡単に排気不能なセットから得られる同じ共有値を計算します。
Note that in this situation if protection was obtained from the methods of Section 3.3, then each user must ensure that the other party's public key does not come from the small set of elements of small order. This can be done either by checking a list of such elements, or by additionally applying the methods of Sections 3.1, 3.4 or 3.5.
この状況では、セクション3.3の方法から保護が取得された場合、各ユーザーが相手の公開鍵が小さな注文の小さな要素から来ないことを確認する必要があることに注意してください。これは、そのような要素のリストをチェックするか、セクション3.1、3.4、または3.5のメソッドをさらに適用することによって行うことができます。
Protection from these attacks is not necessary however if the other party's ephemeral public key has been authenticated. The authentication may be in the form of a signature, MAC, or any other integrity protection mechanism. An example of this is in the Station-To-Station protocol [STS]. Since the owner authenticates the public key, a third party cannot modify it and therefore cannot mount an attack. Thus, the only person that could attack an entity's private key is the other authenticated entity in the key agreement. However, since both public keys are ephemeral, they only protect the current session that the attacker would have access to anyway.
ただし、これらの攻撃からの保護は、相手の一時的な公開鍵が認証されている場合は必要ありません。認証は、署名、Mac、またはその他の整合性保護メカニズムの形である場合があります。この例は、ステーションツーステーションプロトコル[STS]にあります。所有者は公開キーを認証するため、第三者はそれを変更することができず、したがって攻撃を行うことはできません。したがって、エンティティの秘密鍵を攻撃できる唯一の人は、主要な契約における他の認証されたエンティティです。ただし、両方のパブリックキーは一時的なものであるため、攻撃者がとにかくアクセスできる現在のセッションのみを保護します。
This entire document addresses security considerations in the implementation of Diffie-Hellman key agreement.
このドキュメント全体は、Diffie-Hellman Key契約の実装におけるセキュリティ上の考慮事項に対処しています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for Diffie-Hellman primitives", Electronics Letters, vol. 34, no. 25, December 10, 1998, pp. 2396-2397.
[カリスキ] B.S.Kaliski、Jr。、「Diffie-Hellman Primitivesの互換性のある補因子乗算」、Electronics Letters、Vol。34、いいえ。25、1998年12月10日、pp。2396-2397。
[LAW] 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.
[Law] L. Law、A。Menezes、M。Qu、J。Solinas、およびS. Vanstone、「認証された主要な合意のための効率的なプロトコル」、テクニカルレポートCorr 98-05、Waterloo、University of Waterloo、1998。
[LIM] 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.
[リム] 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。
[P1363] IEEE P1363, Standard Specifications for Public Key Cryptography, 1998, work in progress.
[P1363] IEEE P1363、1998年公開キー暗号化の標準仕様、作業進行中。
[PH] S.C Pohlig and M.E. Hellman, "An improved algorithm for computing logarithms over GF(p) and its cryptographic significance", IEEE Transactions on Information Theory, vol. 24, 1972, pp. 106-110.
[PH] S.C PohligおよびM.E. Hellman、「GF（P）およびその暗号化の重要性を計算するための改善されたアルゴリズム」、IEEEトランザクションに関する情報理論、Vol。24、1972、pp。106-110。
[RFC2527] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework", RFC 2527, March 1999.
[RFC2527] Chokhani、S。およびW. Ford、「インターネットX.509公開キーインフラストラクチャ、証明書ポリシーおよび認証慣行フレームワーク」、RFC 2527、1999年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley、R。、「暗号化メッセージ構文」、RFC 2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[STS] W. Diffie, P.C. van Oorschot and M. Wiener, "Authentication and authenticated key exchanges", Designs, Codes and Cryptography, vol. 2, 1992, pp. 107-125.
[Sts] W. Diffie、P.C。Van OorschotおよびM. Wiener、「認証と認証されたキー交換」、デザイン、コード、暗号化、Vol。2、1992、pp。107-125。
Robert Zuccherato Entrust Technologies 750 Heron Road Ottawa, Ontario Canada K1V 1A7
ロバート・ズッカーート・委員会テクノロジーズ750ヘロン・ロード・オタワ、オンタリオ・カナダK1V 1A7
EMail: robert.zuccherato@entrust.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。